2. Excess WIP = WASTE More WIP = longer lead time More WIP = higher probability that one of the stories being worked on will change More WIP = more context switches for developers
3. Solution: Limit WIP Number of WIP slots in development should be proportional to team size (factor to be determined by trial and error) Each slot represents a workflow state In Development (4) Specified (3) Backlog (4) Ready for QA Ready to deploy
4. Limits help to identify bottlenecks Here, the developers working on new features are starved of work because there are no more slots left in the “In Development” board section. In Development (4) Ready for QA Specified (3) Ready to deploy z z z
5. Temporary solution = reassign developers to parts of the board where work can be done Long-term, work on eliminating the bottlenecks In Development (4) Specified (3) Backlog (4) Ready to deploy
6. Where Kanban can borrow from Scrum Daily stand-ups, always held around the Kanban board Prioritisation – maybe with a fast-track across the kanban board for urgent issues
7. Where Kanban differs from Scrum No time-boxed iterations – focus is instead on lead time which can be more consistent and useful than velocity in a project where work is sporadic Detailed estimation considered wasteful Estimating entire backlog is also a waste Scrum limits WIP per iteration; Kanban limits WIP per workflow state
8. Possible benefits Workflow states bear some resemblance to a waterfall methodology and are easy for customers to understand Kanban is suited to ongoing development and maintenance rather than time-boxed, feature-limited projects. In my experience, every project we have done ends up being ongoing.
