Try to minimize work in progress during sprint

December 7, 2018

New scrum teams or sometimes even experienced, have difficulties on how to split and work on the product backlog items (PBIs) during the sprint . Is 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 shorten cycle times of deliverable items and therefore you have feedback loop more often and also happy customers.

 

Littles Law in Software Development:

 

WIP = Throughput * Lead Time

 

where

 

WIP = average number of items in 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 for minimizing WIP. By controlling the time factor, meaning by working on iterations, we achieve to reduce the items to be worked 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 happens in non Agile environments is that multiple tasks are started simultaneously and none of them are finished on time. The reason is because 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 in 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 member 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 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 member 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 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 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 do that they are risking not to finish 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 on other PBIs.

 

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

 

Please reload

Featured Posts
Please reload

Nikos Raptis -
Agile Coach, Speaker & Developer

I'm a scrum master, speaker and software developer. I love Agile values and principles and...

Contact me

© 2015 Created by Nikos Raptis

  • Google+ - Black Circle
  • Twitter Black Round