Coauthor of Agile Manifesto and creator of Adaptive Software Development, Jim Highsmith, characterized Agility as the ability to balance flexibility and stability. “Agility is the ability to both create and respond to change in order to profit in a turbulent business environment”. Mike Cohen, in his book Agile Estimation and Planning, describes change as something that we should welcome! “Change means that we learned something new or we are avoiding a mistake”. How do we welcome change at all stages of product development and deliver value or working product in a consistent, sustainable manner? Answer to that question lies in a simple technique called “WIP Limit”!
What is this WIP? WIP stands for “Work in Progress”. If we discipline ourselves to limit what we work on at any point of time and finish what we started, before starting new piece of work. In other words, WIP limit is the limit imposed on the amount of work-in-progress so that team members are forced to finish the work that has been started before starting on new piece of work.
Irrespective of the Agile methodology followed (Kanban or Scrum), WIP limit plays a cardinal role in Agile Delivery, consistently delivering business value and responding to changes at the same time. Let us see how WIP limit is imposed with Scrum and Kanban.
In Kanban, WIP is limited at every work flow state. Some teams do it by explicitly denoting the WIP limit as number of work items on the top of each state (column) on a Kanban board. When the limit is met at any column, that creates a bottleneck situation and force team members to help their teammates who working on the downstream items to complete it. Another way to limit WIP is by setting limit on number of work item being worked on by any team member at any given time.
In Scrum, Sprint backlog is the work-in-progress limit. After the Sprint is started, no changes are allowed to the Sprint backlog. Typically, team members are desired to work on stories in the priority order within the Sprint backlog. Product Owner is not allowed to make scope changes to the stories in the Sprint backlog during the Sprint. This allows the team to focus on a small subset of the product backlog and deliver them at the end of the Sprint. As you can imagine, unchangeable sprint backlog plays a crucial role in deciding the appropriate Sprint length or time box in Scrum. When priorities are shifting frequently, shorter Sprint length would be more appropriate.
As an end note, it is desirable to limit the work in progress at all levels – Portfolio, Program or Team levels. By limiting the WIP, we are allowing the entire organization to focus on things are of the highest priority! Any thoughts?