Try to minimize work in progress during sprint

New scrum teams or sometimes even experienced ones, have difficulties with how to split and work on the product backlog items (PBIs) during the sprint. In this article I will try to highlight the importance of reducing the work in progress to a workable minimum.

Work In Progress (WIP) and Little’s Law

I believe that many are familiar with the Kanban framework and the core practices it contains. If not then here is a good starting point: http://itsadeliverything.com/littles-law-the-basis-of-lean-and-kanban

One of the core practices, in order to bring balance to the development process, is by minimizing the work in progress (WIP). Based on Dr. Little’s Law, minimizing WIP leads to shortening cycle times of deliverable items, and therefore you have a feedback loop more often and also happy customers.

Littles Law in Software Development:

WIP = Throughput * Lead Time

where

WIP = average number of items in the process

Throughput = average departure rate

Lead Time = average time an item spends in the system

Sprints are minimizing WIP by default

Scrum sprints are a way of minimizing WIP. By controlling the time factor, meaning by working on iterations, we achieve to reduce the items to be worked on during that period of time. (if the velocity of course is taken into account but we assume this is done).

Also, something that many times happen in non-Agile environments is that multiple tasks are started simultaneously and none of them are finished on time. The reason is that in these environments possibly the same people work on multiple tasks, so the switching context prevents them from finishing something on time.

But minimizing WIP only by introducing iterations is not all that we can do!

Minimizing WIP when working on sprint Product Backlog Items (PBIs)

Here the concept is to find ways to minimize WIP when working on sprint PBIs. Below there is a workflow that every person on the team can follow. The reason to do that is again to reduce the risk you take when you start multiple items, which is that nothing may be done eventually.

In a few words, the team should examine how many team members can work on a PBI each time, then work on it and then repeat that examination each sprint day or sooner.

Imagine that we are on planning meeting part 2 and the team chose, based on their velocity, some PBIs to implement in the sprint. Let’s assume also that the order of the PBIs will remain the same during the sprint and the team will work from top to bottom.

They pick for discussion the first PBI and based on what sub-tasks they created earlier, team members are volunteering to work on them. When they agree that there are enough persons for the size or complexity of the PBI, and if there are persons still without a PBI to work on, they pick the next one to examine.

They repeat that until everyone has something to work on. They start the sprint when everyone has something to do. Some team members may finish their tasks the next day or so. In that case, they ask the other team members if they could do something in PBIs which are in progress.

If helping in another PBI which is in progress is not efficient because of inner dependencies, they pick the next PBI in the sprint backlog and start working on it. If a person cannot join or start a new PBI she may choose to learn something new, which can help the team, do some more refactoring in the code, etc.

Every now and then she should ask the other team members if she could help somewhere.

Continuous awareness is the key.

Alignment in daily stand up

Daily stand-ups are the best point in time to make the above discussions about the status of the PBIs and potential collaborations between team members to achieve the sprint goal. Remember that the daily stand-up purpose is to inspect and adapt the sprint goal and make a 24-hour plan.

So team members should have ears open, ask for help if they need it on their PBIs, or volunteer for help in case they finished their part. Of course, we don’t want to wait for the next stand-up to be aligned but this is a chance to do it.

Avoid pre-assignment of all PBIs during the planning

A common pitfall for new teams is to pre-assign themselves every PBI from the sprint backlog from the beginning. This is a way of doing it but most of the time will not be beneficial for achieving the sprint goal.

If the team does that they are risking not finishing all PBIs because each one will see a part of the sprint goal and there is a great possibility of delayed integration and testing between them.

Also, a more complex or bigger PBI will slow down the team members that took it. If it is a norm that no one else cannot join the effort of that PBI then they are in trouble. That can become worse if other team members think that they took work for all the sprint duration, even if it is not so big, and they adjust their efforts without thinking of helping other PBIs.

In a few words, the team should start working on a few and continuously inspect and adapt to achieve the sprint goal.