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.
When you shift a ticket beyond DOING, select another ticket according to the following prioritisation.
The first CRITICAL BUG ticket in TODO.
Someone else's fundamental ticket in REVIEW.
Your fundamental ticket in REVIEW that requires changes.
IF someone is available to PAIR, pair on a READY fundamental FEATURE ticket.
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.
A TEST-RED ticket.
A NON-CRITICAL BUG
A DEBT ticket OR A DEVOPS ticket (your discretion)
We want to be able to release the application at any time. Bugs prevent us from doing that so take the first priority.
When we realise that code is unused or inconsistent we create a DEBT ticket to placehold this issue. Examples:
document table's un-used columns
classification column to a hierchical
ltree datatype to allow more sophisticated and performant queries.
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 tickets are collected into EPICS and relate the following subtypes:
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.
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:
empty (no data)
A COMPONENT will often
have many INTERACTIONS. Use the
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
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
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.
Make the TEST-RED go GREEN. Does not include wiring this functionality to the UI.
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.
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.
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.
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.
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.