Repository navigation
Story Boards
The best story board for a co-located team is a physical one. Not only do they constantly radiate information and encourage conversations, but they are infinitely more flexible that online tools, allowing to you progress beyond traditional scrum and kanban models.
Use a good quality magnetic whiteboard, 3mm gridding tape, ruled index cards and rainbow magnets. Have the team create their own avatars. Laminate them and use disc magnets to attach them to the board.
If the team is distributed then a variety of online boards are available, but be careful to keep things simple. Tools like Jira should be avoided as they are overloaded with features that make them clumsy.
Traditional boards use columns to represent queues. Stories should be ordered by priority and generally progress from left to right.
| New | In Prep | Ready | In Play | Bugs | Demo | Done |
|---|---|---|---|---|---|---|
| Bug | Story | Bug | Story | |||
| Story | Story | |||||
| Story | Story | |||||
| Story | ||||||
| Story | ||||||
| Story |
The choice of queues varies depending on the needs of the project, but avoid boards with two masters. A planning board (for design and discovery), and a work-in-progress board (for implementation) should be two different things, with perhaps a little bit of overlap, when stories are in the late stages of refinement. Some queues to consider...
Valuable if your team deals with ad-hoc support requests raised by other teams. Stories in this queue should be triaged and moved into another queue as quickly as possible to
- Let the author know the story has been noticed
- Minimise delays caused by mis-routing to the wrong team
- Keep the 'New' column empty so issues are more easily noticed
Be suspicious of wait queues. Work that is not ready to be started should usually not be tracked on the same board as work that is ready to start. There is always more work not ready than ready, so you will end up diluting the main purpose of the board. Most of the team will not care about such work, unless it is imminent.
Low priority queues should be avoided. They are a dumping ground for issues that will never be done. We don't like to disappoint but it's better to be honest and close them immediately.
Tech debt queues should be avoided. When a developer creates a tech debt issue, what they are invariably saying is I don't like this code, but I have more important things to do now, and in the immediate future to fix it. I don't want to forget, so I'll create an issue and fix it later. The problem is that the process of creating the issue, generates the relief, and the tech debt no longer seems urgent. Instead absorb refactoring into the issue you are working. If you believe a redesign rather than a refactor is required, spend some time to consider what the new system might look like, call a timeout and make the suggestion. Plan the rework as you do with features.
When using a tool like Zenhub it can be useful to group stories into epics. This leads to epics polluting one of the other columns so creating their own dedicated queue can make sense.
It can be valuable to get a heads up on work that is imminent. It may also be valuable to separate out work which is planned, but cannot be started until an in play, ready or imminent dependency has been resolved.
Valuable to indicate work that has been planned, is free from dependencies and highest priority.
Blocked stories should be addressed quickly. Moving them to their own queue can help highlight that they are blocked, but could equally be managed by moving them out of in play and applying a label or some other clearly visible decoration.
Shows work currently undertaken by the team. I sometimes include stories to track work being performed by external teams that is a dependency of this team.
Some agile teams have dedicated QA members, in which case they should have their own column.
Bugs and support work should be prioritised above feature development. If they are not handled quickly, it is likely the originator will chase, creating additional work and possibly duplicate issues. Using a separate column is a powerful indicator of system quality. A high number of bugs / support issues can indicate more effort needs to be spent on code quality, testing, ux, self-support and admin support tooling.
Valuable for encouraging internal and inter-team demos.
Sometimes an issue cannot be closed, because work is still to be done. It's possible a bug has been fixed, but the originator must be advised. It may take days or weeks for them to respond. Managing such actions via a closing queue, prevents clogging up the board.
The team should have an agreed definition of 'done'. Ideally 'done' will mean live, potentially behind a feature toggle. When unfortunate enough not to be able to release frequently, e.g. when another team is responsible for QA and deployment, then done make have to be a weaker definition, e.g. 'distribution sent to client'.