Skip to content
Vincent Rabeux edited this page Feb 8, 2015 · 7 revisions

Tryout for a new workflow

It uses a mix of Github Issues and Trello Cards for management of ideas, tasks, stories, epics, and bugs.

About roles :

  • POs => {Brandi, CEO, PO, Me}
  • Devs => {Brandi, CDS, Me}
  • Testers => {POs, Devs, Testers}

Use Trello for :

  • ideas.
  • functional conversations about a feature or a bug.
  • high-Level Planning,
  • management,
  • bug report,
  • testing,
  • sharing relevent UI design spec files / PDF etc,

Use Github (https://guides.github.com/features/issues/) for :

  • Technical conversations about a task, implementation, decisions, diagrams.
  • Commits refer to Issues/Tasks/Bugs and can directly close them.
  • Milestone fine grained advancement and pulse.

How to link the both :

  • It is the developper responsibility to link tasks with Trello cards and manage them (Github is easy with commits).
  • There may be several github issues for on Trello Card

Example of a Trello Card :

  • Card 34 :
    • Sub-Task : #9, #10,Card 35, #11,
    • Bugs : #12, #13, #14, Card 36
    • Pull Requests : #11, #15

Examples :

From Ideas to Tasks :

  • Step 1: Ideas. [POs]

    • POs create Ideas in the Ideas column ( 👍 ). An Idea is just a Trello Card with very little description, and in a state that is not understandable by development team.. Here is an example :
  • Step 2: Tasks and Bugs | Backlog [POs, Devs]

    • Moving a Card from Column Idea to Backlog, requires it to be in a state that is sufficient for the development team to estimate the amount of work. ie The description is sufficient enough to understand the need.
    • When this condition is met, the Trello Card is changed :
      • A short but significant title is given to it.
      • The description takes shape and is formated.
      • A label is applied [enhancement, bug, ...]
      • The team member responsible for giving an estimation is given as assignee.
    • The Card is moved to Backlog.
    • Here is a task estimated, ready for development team :

From the Backlog to a Release.

  • Step 3 : The Milestone [POs]

    • A Milestone is both a Trello Card and a GitHub Milestone. Both are defined by the same Date and Version number.
    • A Trello Milestone should have
      • A due date
      • A name
      • A planning checklist that lists all important dates (beta dates, RC dates, Testing dates, etc...).
    • It is the PO role to create the MileStone's Trello Card such as the following :
    • It is the role of Devs to create the equivalent GitHub Milestone and provide the link to it in the Trello Milestone :
  • Step 4 : Planning the milestone [POs]

    • The POs can add any Task from backlog (or new Trello Cards that are estimated) to the Todo column by order of priority.
    • Every task moved to todo should have a list of member : developer(s), tester(s), PO(s).
    • The Milestone in witch the task needs to be completed is last in the order.
  • Step 5 : Task description improvements [Developers, POs]

    • The task is moved to In Progress Column.
    • The POs adds a Trello checklist for testing the task. If the task is technical, the Devs does this list.
    • The Devs creates :
      • If the task is big :
        • A branch.
        • A sub-task list (Trello Checklist) referring each to github issues (with right github milestone).
      • If task is small (1-2 commits MAX) :
        • A link to a new Github issues (in description) (with right milestone).
  • Step 6 : [Developers, Testers, POs]

    • Lets just code ☕
    • Tasks are taken in Order from the Todo column
    • At anytime, the PO can change the milestone / task order within the Todo column. This asserts that Devs have always business relevant task to work on. For example by changing the scope of milestone :
  • Step 7 : Testing [Testers, Devs]

    • Following the planning of the Milestone. Builds are made (experiment branches, sprints, alpha, beta) and sent to testing.
    • Each card is moved or copied to a Column representing the specific builds in which they are solved appear (for example : 1.2.3-beta.1).
    • Testing is done first following cards tests checklists and then if necessary by following the iOS test campagne board.
    • Bugs can be reported :
      • within the original card. (Checklist)
      • as a completely separated card (=> a new github issue will need to be created)
      • Always falls into the same (original) milestone.
  • Step 8 : Bug fixing [Developers, Tester]

    • ...
Clone this wiki locally