Talkilla/Agile Process
Note: Talkilla has now been superseded by the Loop project
Contents
Introduction
Talkilla uses an agile development process.
The process is based around user stories. User stories are typically discrete user focused use cases. Each user story is aimed at building one small feature on top of the existing product.
Sometimes user stories can also be entirely technical. This occurs when sometimes we need to break down a larger story into a smaller part, or we need to do some refactoring because the technical debt has gotten too high. Generally we try to avoid this latter case by cleaning the code as we go.
The advantages of handling the project as small chunks of work, is that each bit of work moves the project forward. Additionally, we can sometimes change direction and focus on different areas without a big time switching cost.
We use Trello to track the user stories, as it gives us enough fields to be flexible, and easy ways of visually tracking the cards
Creating the Backlog
The Backlog is the feeder for the main development process. It is primarily managed by the Product Manager with the help of the User Experience lead.
Creating user stories
The Product Manager and User Experience lead work together to produce the user stories for a particular area or areas. Additional input is sought from the Engineering lead and the engineering team as necessary.
The cards are pieced together on the backlog:
Estimation and Prioritisation
Once the user stories have been created, they are estimated and then prioritised. These actions happen in the three left-most columns of the backlog:
Estimation
There is an estimation meeting every week to estimate cards in the estimation column. The cards are discussed, and then given an estimated rating of the amount of work they will take.
The ratings are 0, 1, 2, 4 or "too complex to estimate".
Typical examples of a 1 are these:
The other scores are relative to the 1s.
Prioritisation
The Product Manager regularly moves the cards from needs prioritisation to the prioritised column, setting them in priority order from highest first to lowest. There are various factors which determine the order of the cards, such as:
- Features may be wanted earlier so that they can be validated earlier
- It makes sense to get some features working before others
The Engineering lead works with the Product Manager to implement the user stories in the appropriate priority order as far as possible, taking into account engineering considerations, e.g. it makes sense to implement one user story in advance of another, and avoiding large conflicts from working on two large items in the same area of the code base.
Development
Managing development happens on the main Talkilla Trello board.
Good First Bug
This is a column where smaller, easy bugs are put, so that contributors can get involved in the general development process with something easy. These are typically lower priority cards that aren't time sensitive.
To Do
This list is added to each week with new items from the prioritised backlog. When an Engineer becomes free, they either look to help on an existing card in the "Doing" column, or take the next card from the top of the "To Do" column.
Occasionally, Engineers may take from lower down the "To Do" column, if it makes sense due to time considerations (e.g. just about to go on holiday) or if something has been missed, or is urgently needed (i.e. bug fixes).
Doing
As a card moves into doing, it has a technical checklist added to it. It is also tagged with who is working on it.
As the card progresses, the checklists and state are updated.
See also, our documentation on how we handle the general flow of pull requests.
Blocked
A card in the Blocked column, has been blocked from being implemented by a significant issue, e.g. needing external fixes or some other issue resolution. These are actively watched to obtain a resolution and to get them moving again as soon as possible.
To Be Reviewed
The card has been completed, but is waiting code reviews for the pull request.
Done
This is a dated column, with the old Done columns being moved to the Talkilla Done board.
For a card to make it into this column, the following must apply:
- the feature has been implemented
- includes additional unit or functional tests as required
- passes all tests
- code reviewed, paired, or rubber-stamped
- Any SPA API changes are documented
