Process

[alloy]

I have created several pages on our wiki that describes an initial draft of how I think we should think of our process: https://github.com/artsy/mobile/wiki

I’d like you all to read through all of those pages and provide feedback about what you think should be different and how it should be different.

Some specific things:

• Should we change our weekly standup to be on Monday morning? And if so, how late?

• @katarinabatina / @briansw How feasible is it for you to start writing down design decisions as user stories as you create the design? https://github.com/artsy/mobile/wiki/Specification

  If an automated tool is needed, we can at some point look at Anthology again. Possibly make it possible to export an overview of stories as markdown, which makes it easy to move them to an EPIC ticket.

• @ashfurrow and @mennenia I’d like your feedback on what does and does not work with the process described in: https://github.com/artsy/mobile/wiki/Verifying-understanding-of-design

[mennenia]

Firstly: This is amazing <3.

Here's some thoughts on the various pages / issues.

— Process

I love the icebox

I am very happy to see “in progress”. Yes it’s self-explanatory, but that way everyone is more aware of what’s going on.

— Issues

What is an issue? Is it a ticket / piece of work? Often we also use it to catalogue a whole host of information and it’s getting slightly confusing to me.

I’ve seen single task / small task tickets.
I’ve seen overarching tickets.
I’ve seen design specs, which aren’t necessarily how one would implement them, so one would need to create separate development tickets — to me signalling that the design spec should be in some wiki of some sort.
I’ve seen overarching tickets with sub tasks. Some of those link to other tickets, some don’t.

I think issues should have a task with a concrete outcome. If they require further subtasks, one can create those as they are encountered or as they are planned. But they are separate from the information you need in order to get them done. They should link to that information or contain possibly a short paragraph, but that way the information can be rich, expansive, up to date and provide full context, without needing to “fit into an issue”.

— Place

Which leads me to a place to store this. I personally prefer a wiki rather than anthology.

I think if we have a template we stick to in order to record the right information, everything should go in one place. Especially something that can link to everything else, so it’s very easy to see context, see where decisions came from, what the assigned tasks were, who worked on them, and what the outcome ended up being, where and when the code got merged, and so on. PRs, designs, user stories, personas, issues, bug reports, analytics requests all coming together in one system, but each having their “home”.

— Personas

I know they seem odd, some people even like to call them made up people, but they really help to understand why we do things. I see them as the unit tests of a design. These are people who we are creating the product for, and they should really help to

1. clarify the purpose of Eigen. If we tried to satisfy 8 different people, we know we’re in trouble and need to simplify
2. help us balance choices like the discussion from Friday around the gene page. Who are we trying to create this feature for? It can be more than one person / use case, but that way the discussion is concrete and we know who the players are.
3. make it immediately clear what a design / decision is for. We’re implementing this new feature, so it’s more clear to a collector what the history of this work is. Boom, easily understood. Instead of “make it more clear what the history of the work is”. Okay. Why? For whom? You can’t help but ask those questions.

They would go well with our user stories.

— Verifying understanding of design

I think one of our goals should also be to be less surprised by the time a ticket lands on our lap.

If we include early designs in our weekly standup, so we see how they evolve we have that background knowledge.

However, doing a proper run through an almost finalised design is 👍 and definitely something to add. Perhaps we can make this part of our QA period in a sprint? That way design has had the four weeks to prepare the materials for the upcoming sprint. We can review in QA period as mentioned in this section. We can discuss, and they can then be primed for estimation at the beginning of the next sprint?

— Estimation

I’m down, if anything to determine the velocity so we can get a better grasp of future planning. Eigen will be going through a lot of changes over the next few months, and features will hang together (like onboarding + home screen), so it’d be great to start learning when to expect such epics to be shipped. That way we can notify relevant parties (marketing, copy, visual design for promotion or something, and so forth).

I’d love to see a little timeline on the front page of the wiki, so anyone from the company can easily see what’s going on with Eigen and what’s coming up (which should also help avoid the need to clarify what is part of the sprint and what got shipped, like we saw in the product meeting recently).

Also, I think every EPIC that’s been assigned to a sprint should have a dev owner (who can ask for help / get others onboard if and when required).

— Weekly standup

I think it could do with some tie to the overarching goals as well. What’s the progress of the project, how is what we’re doing / designing right now tying back to what we want / need Eigen to be.

— Specification

I have some thoughts here but am going to defer to Katarina and Brian for now.

A selfish request would be that perhaps the text wouldn’t go in the image, so it’s easier to read in one page (rather than zooming in through the image). But this isn’t up to me ^_^.

I do want to reiterate as I mentioned to Katarina last week that I think it makes more sense for development to break up a design spec into tasks, as design doesn't necessarily know how we'd approach it (e.g. separate modules like in the Onboarding epic), and that the approach would probably also vary from developer to developer.

[sarahscott]

Estimation

• Planning Poker sounds like a great idea, especially since our individual knowledge of eigen varies and sometimes issues that seem simple can quickly become rabbit holes.

Issue Classification

• I'm still a bit unclear on what makes an EPIC epic.

Specification

• I love the idea of including user stories in specs. I think right now, we're all curious enough to ping Katarina for this and it'll save some time if it's automatically included going forward.

Verifying understanding of design

• I don't like using a lot of paper. Is it ok if we do this with a stylus on an iPad or something? 🍃 🌴 🌲 🌳 🍀

I think everything I haven't commented on is great!

[ashfurrow]

our individual knowledge of eigen varies and sometimes issues that seem simple can quickly become rabbit holes

Sarah, this observation is 💯 Planning poker would be a great way to mitigate tribal knowledge.

@alloy the understanding design page is amazing ✅ I'd add that part of the process should be identifying missing (or ill-defined) user stories. Ultimately, the goal is to give everyone a snapshot of the entire system: in terms of user stories, visual design, and implementation details. That context would be really useful in estimation.

[alloy]

I’ll come back to all your great feedback tomorrow, I just want to clarify a bit more around the use of user-stories.

These are stories we (the developers) would write. We do that by sitting down with the person that is responsible for the design and having them give us a walkthrough and us asking questions. Specifically, the right questions, which is where user-stories (as a tool) help out.

[katarinabatina]

Posting my feedback to be discussed tomorrow:

Overall response to this is 👍 👍 👍

My takeaway is that there are two major goals here: 1. Provide more context for why we have conceived a particular feature in a certain way and 2. Have more clarity on what needs to be done to implement a certain feature.

To address these two things, I think at a high level our process could look something like this...(some of this we already do)

• GMV iOS sprint kick off: At the beginning of each sprint we discuss what we shipped last and what we plan to ship next, outlining each feature and discussing the "why" as it relates to our longterm roadmap and team KPIs.
• GMV iOS Weekly: This is a meeting at the start of each Monday where we as a team discuss what we are planning on tackling for the week. Additionally, I or said designer will present a quick status update for where I/they are in a particular part of the design process. (This meeting is different from a Mobile dev standup in that we will discuss the what, why, and how we're tackling work related to GMV iOS goals) I encourage a separate Mobile Dev standup where questions around implementation around all projects touching Eigen can be discussed.
• Wake.io discussions: As apart of the design process I will (more frequently) post progress of particular features I am working on an @ any engineer who plans on working the feature to get feedback. This will also be the best place to understand "why" we are working on a particular feature.
• Design Walkthrough: Hopefully between GMV iOS Weekly and continues discussions in Wake, the design walkthrough will be a moment to bring together designer and engineer to walk thought the finalized feature and discuss the desired user experience. Here the goal is to answer the "how" meaning, how will this be implemented. The product of that walk though should be an outline of how the engineer would like the feature split up into github stories. This will also be a time for an engineer to define user stories with the designer as they find helpful to furthering their understanding of why features are being implemented.

I'm hopeful that these couple of steps will bring us closer to giving more context to our work without introducing too many new processes to how we work today.

[mennenia]

I am a fan of engineers being @-ed in wake ^_^ (seeing as it's a process the design team already uses and works for them).

[alloy]

@mennenia

— Issues

I’ve done a bit more describing on that in https://github.com/artsy/mobile/wiki/Issues.

— Place

Which leads me to a place to store this. I personally prefer a wiki rather than anthology.

I think all information that the engineers collect in order to get a designed feature implemented should go into Issues, at the right level as defined in https://github.com/artsy/mobile/wiki/Issues. I don’t want to have to jump to too many external tools when quickly jumping through issues from e.g. the ZenHub board.

On-going design work will be in Wake, after the design walkthrough we will tell the designer in what form we want the feature design to be split up and spec’ed, which then, as said above, I think should go into Issues.

The anthology suggestion was only meant as a tool to use while writing down user-stories, not to keep them there. (I can no longer write human-readable text by hand, nor am I fast enough at it 😉)

— Personas

I don’t think we need a whole lot of that, it should be really clear by now that Eigen is going to focus on collectors. There is definitely a lot of room for improvement/expansion/addition of role definitions on https://github.com/artsy/mobile/wiki/Specification, though.

— Verifying understanding of design

[…] Perhaps we can make this part of our QA period in a sprint?

Good idea https://github.com/artsy/mobile/wiki/Meetings#feature-estimation

— Estimation

if anything to determine the velocity so we can get a better grasp of future planning

Added 👍

I’d love to see a little timeline on the front page of the wiki, so anyone from the company can easily see what’s going on with Eigen and what’s coming up

I’m not sure. It’s something that needs to be kept in-sync (i.e. I worry about it going stale) and I’m not sure others in the company would really use it, they probably prefer to get their info from the product meetings, which is where @katarinabatina includes such information.

For us, getting an up-to-date overview of the queue is a matter of looking at the ‘Backlog’ pipeline of our ZenHub board and filtering by ‘EPIC’.

(which should also help avoid the need to clarify what is part of the sprint and what got shipped, like we saw in the product meeting recently).

That should just be taken from the CHANGELOG. /cc @katarinabatina

— Weekly standup

We’ll have a GMV team meeting and a separate mobile engineering standup: https://github.com/artsy/mobile/wiki/Meetings#gmv-ios-weekly

— Specification

A selfish request would be that perhaps the text wouldn’t go in the image

it makes more sense for development to break up a design spec into tasks

The definition of what issues should look like and how design should be split up and spec]ed is up to you
as the engineer that ‘owns’ a feature. https://github.com/artsy/mobile/wiki/Specification#visual-design, https://github.com/artsy/mobile/wiki/Meetings#feature-design-walkthrough

[alloy]

@sarahscott

I'm still a bit unclear on what makes an EPIC epic.

I’ve tried to describe it a bit more in https://github.com/artsy/mobile/wiki/Issues#types, but it might still not be fully clear. In which case I invite you to do a 15 minutes of research into the topic and add a summary that helps you to that wiki.

I love the idea of including user stories in specs. I think right now, we're all curious enough to ping Katarina for this and it'll save some time if it's automatically included going forward.

It won’t be, the stories will be something that we write during the design walkthrough, based on our understanding of the design. https://github.com/artsy/mobile/wiki/Meetings#feature-design-walkthrough, https://github.com/artsy/mobile/wiki/Specification

I don't like using a lot of paper. Is it ok if we do this with a stylus on an iPad or something?

👍 I’ve added a note to https://github.com/artsy/mobile/wiki/Verifying-understanding-of-design that explains this a bit more.

[alloy]

@ashfurrow

I'd add that part of the process should be identifying missing (or ill-defined) user stories.

Mind adding that to the wiki page? That page is still very rough.

[alloy]

@katarinabatina I have changed the standup page to be about all types of meetings and have now made a distinction between team concerns and engineering banter https://github.com/artsy/mobile/wiki/Meetings.

I also added a very rough draft of how your side of the process looks like, it would be great if you could give that a look over and better describe it https://github.com/artsy/mobile/wiki/Design-Process

[alloy]

These are all the changes I made to existing pages:

• Issue Clarification -> Issues: https://github.com/artsy/mobile/wiki/Issues/_compare/330877365578bb12dce321fa403701d5a959e489...b4b2291f68d7743bee2b3284fc8ee8189c62f8be
• Weekly Standup -> Meetings: https://github.com/artsy/mobile/wiki/Meetings/_compare/f93eb34690c956d2aa2ae4dc8d0dfed813e30105...e4a5bc16d77953f9eb604842b5d9e0e292e14470
• Estimation -> Planning: for some reason there’s no history for that page, mainly added ‘Prioritisation’.
• Process: https://github.com/artsy/mobile/wiki/Process/_compare/5a6446e5a5d5818a8ee90b5cc8fec8d1a0719784...27665096265abc67e3cbb3f948117ed4256b5867
• Specification: https://github.com/artsy/mobile/wiki/Specification/_compare/ac4428bc64961489ac396c78cf59994897e88186...2a4e85de709abe85f2dd79a6fbe5ca8f89b67e8e
• Verifying understanding of design: https://github.com/artsy/mobile/wiki/Verifying-understanding-of-design/_compare/37ca7eef9071286e6c332cfe7de73571e2c3fc9a...24982c2ec4bd3c4baed3469b81860ce108b5f21e
• Versioning: new