Skip to content
This repository has been archived by the owner on Aug 22, 2018. It is now read-only.

Process

Jump to bottom
Eloy Durán edited this page Mar 29, 2016 · 16 revisions

We use ZenHub boards to implement workflow tracking using the Kanban method.

As we use ZenHub across several teams, our boards are augmented by repos, labels, global/sprint milestones, and the stages (pipelines) across the board. Issues are further described in Issues.

Milestones

As shown in Issues#classification, we have two types of milestones.

  • Sprint A fixed amount of time during which development, QA, and release takes place. We are currently on 4 weeks of development and 2 weeks of QA + release.
  • Global Milestone These are all the issues that make up a holistic high-level feature and usually spans multiple sprints. E.g. the introduction of ‘Live Auctions’ is such a milestone.

Pipelines

Note 1: Because we share our boards across teams, there may be some pipelines on the board that are not relevant to us. E.g. The auctions team has ‘sprint’ pipelines that are named like ‘April 22nd’. You can simply collapse those pipelines.

Note 2: The following stages are currently largely based on those described on the ZenHub blog and should be amended to fit our specific workflow.

Each pipeline definition may link to another page that expands on what it is or how to perform the work in that pipeline.

  • New Issues This Pipeline is the landing point for new Issues. During Meetings#gmv-ios-weekly we review and prioritize all Issues in this pipeline. Anyone from the team can create an Issue at any time and know that, through this process, it will be visible to everyone. The triage meeting should always end with an empty 'New Issues' pipeline!

  • Icebox The Icebox represents items that are a low priority in the product backlog. We don't want to delete these and create a cycle of raising duplicate issues, so we keep them in our icebox with just enough information attached that we can pick it up some time in the future -- if and when we choose to do so.

    Icebox Issues should not take up a team member’s time or mental bandwidth; we find that putting ideas into the Icebox Pipeline gets them out of our heads and helps us focus on immediate priorities.

  • Specification This is where an assigned team-member goes through the EPIC issue and design and verifies their understanding of the provided design, asks for clarification, amends the EPIC issue, and/or creating new lower-level issues. Finally any of these understandings or changes therein should be discussed with others in the team.

  • Estimation This Pipeline is for items that need estimation, without which it will be hard to prioritise certain issues over others.

  • Backlog This Pipeline is a prioritized backlog of items ready for development. The Backlog is used heavily during sprint planning meetings: the higher an issue is on this list, the higher the priority. Higher-priority items will typically have more in-depth information attached, and we keep all our use cases and requirements in the Issue comments.

  • In Progress This one is self-explanatory! Each Issue in this pipeline should have an assigned owner who is responsible for its completion. If a team member decides to take on a task, she or he simply self-assigns the Issue and moves it to the In Progress column, instantly communicating to the rest of the team that the task is underway.

  • Need QA We use this column for Issues that are open to the team for review and testing. Usually this means the code is deployed as a beta build available from TestFlight.

Clone this wiki locally