Limited WIP: Tasks vs Stories
Hi all
It's pretty well understood that limiting Work In Progress (WIP) is a good thing. Ideally WIP should be limited to one item in progress at a time. This minimizes inventory-on-hand (waste) and...in theory at least...gets value out of the door more quickly.
This principle of Single Piece Flow (SPF) is central to Lean Kanban ways of working, especially in a manufacturing context. In a software context however, WIP tends to be higher. It is often limited to one item per developer, such as by allowing each developer only one avatar to place on an item, and it can be reduced further if pair-programming is in use. As such, software teams might not often achieve SPF but the value of limiting WIP as far as possible is still understood.
There are however problems in interpreting limited WIP in Scrum. This is because a Scrum board will often take the form of a task board...not a Kanban board. In other words, the work being limited by Scrum teams is not always a user story or similar requirement. It is often a task.
Task-limited WIP allows developers to progress tasks from any user story in any order. They could potentially do one task from one story, then a task from another, then a task from a third. In effect, three or more stories - perhaps even the entire Sprint Backlog of stories - can be in progress before so much as one story is completed.
None of this breaks Scrum rules. There's nothing to stop a team, in Sprint Planning, from organizing the Sprint backlog into any number of tasks which can be progressed in any order they choose, and from delivering all of the user stories in one go at the end of the Sprint.
The Sprint Goal can of course be met by this approach, and there should still be a nice task burndown to show the associated technical risks being managed. The problem is that it defers approval of each user story to the end of the Sprint (i.e. the Sprint Review), when it is best practice to get continual sign-off by a Product Owner throughout a Sprint. This allows the business risks of deliver to be managed well, and not just the technical risks.
I'd like other people's thoughts about this. Is it important to limit WIP in terms of user stories rather than tasks, so we can get early inspection and approval from a PO? Or does this approach to limiting WIP amount to Lean-Kanban by the back door?
Hello, Ian
Great question. Really glad that you've brought this topic to the forum.
I'm using WIP with all my Scrum teams. You're right saying that in Scrum we have a task board rather than a Kanban one.
It's definitely needed to limit Story In Progress (SIP), not tasks to shorten the lead time and maximize the probability of finishing all the Stories in a Sprint and achieving the Sprint Goal.
Nothing prevents a Development Team from starting all the tasks from different stories all at once. Scrum says nothing about that. The Sprint is a black box, a container. I tried both approaches and limitng SIP works in practice.
I call it a ScrumBan. In fact, the owner of the term Corey Ladas calls it ScrumBan Level1.
The formula is simple:
ScrumBan = Scrum + Kanban
I use Scrum as a strategic tool and Kanban as tactic one.
WIP, task board, burndowns are not defined by scrum but are useful practices.
I agree that a developer should only work on one task at a time but the team should also work on as few stories as possible. If they can swarm on one story to get that to done in the beginning of the sprint, that's ideal, but how to organize the work is up to the team. During the daily standup the team should organize/replan to maximize chance of meeting the sprint goal. For example team members should take on tasks from started stories until these are all finished, instead of working on a new task from a new story. I think the new questions in the updated scrum guide emphasize this, i.e. "what am I going to do to help the team meet the sprint goal" instead of "what am I going to work on today", which could be interpreted as taking on any task of choice.
I also prefer to let the burndown show completed stories and not tasks. As you say you may have 90% of all tasks done but not a single story done, in which case the burndown will show false progress.
Frederic,
It's 'ideal' if developers can swarm on one story and complete tasks on that story so it can be considered 'Done' before looking into other stories. However, our team typically runs into a problem where the same code artifact has to be touched on by multiple developers to achieve this. We frequently encounter code merge issues(We use .git/gerrit for source control) and spend more time resolving the code conflicts. This is a waste. Therefore, we are only following this to the extent possible that this issue doesn't surface. However, we ensure that as soon as a task for an 'in progress' story is free of such dependencies, it is picked up before any other random task.
This should be a fairly common issue and wondering how other teams handle this.
And I agree, any burndown using stories is more accurate.