Creating our Kanban process – Stages and Queues
Inspired by the work of the Limited WIP Society and kanban community, I set on my journey to create my very own kanban process for my team of me and my subject matter expert/product manager/QA.
First we identified the stages and queues of our development process. We decided that the process starts with the Analysis of a work item. To be quite honest some informal analysis and some preparation work to clear out dependencies takes place before that but we did not formally include it in our process. Most of it is tracked at the road map level. The analysis yields one card, trimmed to a manageable size with the acceptance criteria expressed as a few BDD-style scenarii.
Then there is an Analysis Complete queue. It buffers developers.
Then there is the development in progress stage where cards are again actively worked on. We try to follow best practices for the most part. A card cannot leave this stage until the tests pass, the reports are fine (no cyclic dependencies, no significant PMD or FindBugs warnings, enough coverage) and the acceptance scenarii have been automated with cucumber (and the awesome cuke4duke maven plugin).
Then there is a development complete queue. It buffers QA.
Then there is the QA in progress stage. This is about verifying the scenarii manually and verifying their automation. Any issue or concern raised is immediately addressed. If the issue needs tracking, an issue card is created and attached to the card.
Then there is the closed stage which is the exit of our process.
We do not track statistics internal to the process aside from the cumulative flow diagram. The administrative cost of that seems too high for such a small team. We do track the cycle time of each card in our process.
I will write more on the observations from the first month in an upcoming post.
