Kanban Guide

All work within our organsiation should be visible.


This process has the following goals:

  • make it clear what the priorities are

  • to keep track of how we resolved the issue

  • to point out dependencies

  • to make standups effective

  • to reflect on the mix/makeup of our work during retros

  • to decompose tasks into small achievable units

  • to make sure code follows standards

  • to disperse the knowledge of what is being done and good coding practices

  • to verify the correct functioning of the code

We attempt to achieve these goals by:

  • placing tickets on a kanban in a prioritised order

  • making a distinction between different categries of work

  • breaking feature tickets into design, component, test-red, test-green, and implementation phases

  • making a distinction between tickets that embed fundamental assumptions into the software (fundamental) and need a second pair of eyes; and tickets that do not.

  • test driven development

  • pair and mob programming and code review

The Pair Programming and code reviews share the same goals:

Target: more the half of fundamental tickets SHALL be done with pairing OR mobbing.














done (staging)





When you shift a ticket beyond DOING, select another ticket according to the following prioritisation.

  1. The first CRITICAL BUG ticket in TODO.

  2. Someone else's fundamental ticket in REVIEW.

  3. Your fundamental ticket in REVIEW that requires changes.

  4. IF someone is available to PAIR, pair on a READY fundamental FEATURE ticket.

  5. IF the number of tickets in PAIRED is 0 OR GREATER THAN the sum of tickets in REVIEW AND REVIEWED you MAY SOLO on a READY fundamental ticket.

  6. A TEST-RED ticket.


  8. A DEBT ticket OR A DEVOPS ticket (your discretion)


  1. We want to be able to release the application at any time. Bugs prevent us from doing that so take the first priority.

Todo Swim Lanes

Technical Debt Column

When we realise that code is unused or inconsistent we create a DEBT ticket to placehold this issue. Examples:

  • remove the document table's un-used columns url and unique_name.

  • switch the organization table's classification column to a hierchical ltree datatype to allow more sophisticated and performant queries.

Devops Column

A DEVOPS ticket describes a "devloper story" that improves feedback from the system to developers. Example:

  • WHEN code is pulled into the dev branch from a feature branch, RUN e2e tests

    • on PASS, notify slack

    • on FAILURE, revert merge, and notify merger in slack

    • SO THAT larger tickets developed off the main development branch meet higher test standards AND the main development branch is kept clean for other developers.

Feature Column

FEATURE tickets are collected into EPICS and relate the following subtypes:

1. Design

DESIGN tickets will pass through the TODO, DOING, and REVIEW stages, BEFORE dependent tickets of the same feature can begin. Design will usually produce the design of an entire PAGE.

2. Component - (fundamental)

A PAGE will have many COMPONENTS. Each COMPONENT will have many STORIES. Once the design is READY we can break it down into separate UI COMPONENT tickets. Some components may already exists and can be reused. Others require building as separate tickets. A UI ticket is NEVER an entire PAGE.

A COMPONENT will usually have multiple states. We can specify how the component will look under each state using the storybook STORY concept. The test framework also translates a story into SNAPSHOT test case. For example common component states include:

  • sub-component open

  • sub-component closed

  • empty (no data)

  • validation error

  • warning

  • loading

A COMPONENT will often have many INTERACTIONS. Use the storybook action feature to specify how the component triggers actions outside of updating its own state.

A COMPONENT ticket will produce a [component name].story.test.js file and the compoent file. These files SHALL be placed in its relevant DOMAIN folder. If the component is generic or relates to multiple domains place it in the components/folder.

COMPONENT tickets are fundamental code and require REVIEW UNLESS you paired on the ticket. When components are yet to be INTERGATED into the app, push components changes to the dev branch. If INTEGRATED components require modification push to a speparate branch component/[name]

3. Test - RED

Developers and stakeholders can determine the functionality requirements of FEATURE. Often a requirement is a database QUERY or MUTATION or a combination of a MUTATION and service coordination (emails, uploads).

We can specify the expected functionality as integration (and sometime unit) tests. TEST tickets can be worked on in parallel with COMPONENT tickets in the same FEATURE EPIC.

Tests allow us to develop faster and communicate our understanding to other developers. RED tickets will produce a set of FAILING tests. Push these a separate branch feature/name and shift to DONE. The subsequent GREEN ticket are now READY.

Working this way allows the devlopment team to share responsibility (and understanding) for feature code. One developer may work on writing tests. Another developer or pair may work on passing the tests.

4. Test - GREEN - (fundamental)

Make the TEST-RED go GREEN. Does not include wiring this functionality to the UI.

5. Implementation - (fundamental)

Bug Column

Bug tickets are highest priority in our To-Do Backlog. Bug reports can either be critical or non-critical.


These tickets are highest priority, developers should always choose these tickets to work on first before any other ticket. Critical bugs affect the softwares expected functionality


Unexpected occurrences that do not affect the intended functionality are called non-critical bugs. These usually entail cosmetic issues.

Find out more about our process for reporting and clearing bugs.

In-Progress Columns

We like to limit work in progress. And limit the amount of tickets in the doing column. People should only be working on one thing at a time.


All epics that are being worked on or are in complete sit in this column. All tickets of that epic are in Doing until ticket is viewed as done. IF paired then the ticket can move straight into the QA Paired column IF solo then the ticket will move into Needs Review.

Needs Review

All tickets that were worked on solo go into Needs Review. Tickets are then picked up by another developer, the commits and/or pull request are reviewed.

When review is done, these tickets are moved into QA Reviewed.

QA Column

The QA column is split into two sections: Reviewed and Paired. During stand-ups if we see an uneven ratio of tickets split between the Reviewed and Paired columns, we will prioritise paring on the tickets shifting into doing that day.


This column holds all tickets that have been reviewed. Ticket that flow from Doing to Needs Review to Reviewed were not developed by pairing.


All tickets that were developed with Pairing or Mobbing skip the review column and go straight here.

Done - Staging Ready

Tickets are shifted out of Review as they get tested and verified on a QA Environment of the application. Tickets that sit in the done column have been checked and are ready for the Build Boss to push a release to a Staging Environment from the QA Environment.