You hear about Kanban all the time. There are great guides out there but you do not know where to start. Is this the case? I had the same problem too. So I tried to gather some really baby steps of implementing a simple Kanban system for your early development phase.
For some time now I worked with Trello. I like the UI (maybe not their latest change) and the overall simplicity of the platform and its free!
Want to get a whiteboard? or a SaaS app? draw a Kanban board and the game is on.
As the process is gradually changing, we find new useful things to add or things to remove. So in one month this board may not be the same.
The most important thing in Kanban is flow!
And don’t forget that in every agile process, the definition of Done is really important!!! everybody in the team should know when something is “done”.
Here’s a working example of a Kanban board. You can start by drawing the following columns:
Backlog: Put all your ideas there as they come in. This can only be a repo of ideas – either large features (epics) or small user stories. Big epics though have to be analysed and split in small user stories before they can be put in this column.
Planned: In this column we put user stories from the Backlog that we choose to work with. A good strategy is to have a biweekly meeting with your team to select which features will make it to this column from the Backlog, something very similar with the the Sprint Planning meeting in SCRUM. In my team we use 2 week iterations (sprints).
Some teams prioritize the features in this column, but some do not. Bugs could be added in this column as they come too. Some people create another column next to “Planned” that may hold these bugs.
In Progress: In this column we have user stories and bugs that are currently in development. Devs pull from Planned and add to In Progress.
Two notes here: In each column we can have a Work in Progress (WIP) limit. This is very important in Kanban flow and it means “How many stuff I can do at the same time”. A WIP of 3 would be ok for starters.
*One small note about the WIP limits. The intial number is not validated until several days and try-outs. That way you may end up with a nymber that best suits your needs.
There is a nice Chrome extension for Trello called “Kanban WIP for Trello” and can give you color information when you are at the WIP limit or over it.
If you start having bugs and tasks (like Technical Stories) that should be added in the In Progress column you will quickly get over the WIP limit. There are ways to overcome that – like puting the in their own column or do not count WIP towards these bugs. The reason is that bugs are often urgent and quite small. Technical Stories are related to infrastructure tasks / imporvements or tests. Their main job is to improve quality and make life easier for the team. So in a way they are making our overall process better and there is no reason to count them towards the WIP.
What I like is adding another column next to In Progress in order to prevent a potential bottleneck prior testing. If you want to show that a story is finished by the dev and is ready for testing, add a column Ready for Testing. This will actualy act as a buffer. The difference between WIP columns and buffer is that buffers are clearly waste. Stories here are sitting and waiting and the larger the buffer the larger things take. Theoretically in a perfect system a User Story finished from development should be taken directly for testing. The good thing with this column is that it makes it clear for someone to see that the story was developed but not tested!
The person that will do the testing will pull a story from this column into the next (Testing).
Testing: shows stories that are curently in testing. Put a WIP limit too (2 maybe?)
And after the Tester finishes the story goes to….. Done.
This is a small and as simple as possible example but it should be more than enough for the team to start getting agil-ish…
Author: George Psistakis