WIP is an acronym for ‘work in progress’ and refers to the work which the scrum team are working on during the current sprint.
It refers to the sprint backlog items the team are working on as well as the items which they may have started working on but have needed to set aside whilst they wait for something else to happen or a solution to the impediment that is blocking progress.
It’s a great tool for both scrum masters and the development team to understand how much work is currently in the sprint and how effectively the development team are able to work through those items to deliver a working increment or achieve a sprint goal.
Keeping an eye on the work in progress limits empowers a scrum master to understand whether the development team have taken too much work on for a particular sprint or whether they are in danger of having multiple context switching scenarios that can create barriers to delivery.
As a scrum master, you are trying to limit the number of points in a particular sprint backlog.
If you have six members of the development team, you may have 3 to 6 items in the sprint backlog but you would certainly avoid anything over double digits.
Because you are learning to find the balance between work in progress and how effectively those items can be delivered. You are learning the cadence at which the scrum team operate and what the optimal amount of sprint backlog items per sprint could and should be.
If there is too much work being taken on, it’s going to result in a sprint failure. The team will simply be unable to meet their sprint goal or they are going to run into problems that prevent them from being able to deliver a working outcome for each sprint.
Limiting the number of items on the sprint backlog helps prevent the team from wasting time and effort working on items that they don’t need to or won’t be able to deliver within the sprint.
WIP (work in progress) is an incredibly interesting thing for a scrum master to play with. Analysing WIP can help scrum masters determine what the right number of sprint backlog items per sprint should be. It helps them identify potential bottlenecks and impediments in the organisation and helps them formulate a plan to remove those impediments.
As a scrum master, you will often be asked what the ideal number of sprint backlog items per sprint should be but it’s not that simple a question to answer.
It depends on the scrum team, it depends on the kind of work they are doing, it depends on the environment within which they work and a multitude of other factors.
As a scrum master, you are using WIP to understand what the best number for your specific team is and how consistently they are able to complete all the sprint backlog items within a given sprint.
You will be able to accurately predict, over time, how many sprint backlog items your team are able to deliver on within a given sprint cycle and help the team during the sprint planning process to achieve an optimal balance.
Monitoring the WIP also ensures that if a team member is unable to progress with a sprint backlog item that it doesn’t get lost in the process. Instead of setting the item one side and assuming that someone else will take care of it, you can proactively work with the team to swarm over that item and potentially provide a solution or decide to put the item back into the backlog for a later date.
You’re tapping into the team’s problem-solving capability and asking the team how they can collectively address the impediment to progress.
If it is outside the development team’s capability and requires attention from someone in the organisation that is not a part of the development team, the scrum master can pick that up and work with the individual(s) necessary to remove the impediment to progress.
Either way, the item is flagged as a blocked item and is addressed immediately.
You must have that kind of wiggle room in a sprint because the realities of working in a large organisation is that some things simply don’t move quickly. Sometimes it may even need for a committee to meet before a decision is made and the impediment is resolved.
Our goal is always to complete an item in the sprint. If we have flagged the item as blocked, we bring it back into the sprint as soon as the problem has been resolved and ensure it moves to ‘done’.
We want to keep work in progress front and centre. We want to ensure that we are always working on the right items in the right way. We want to make sure that no effort is being wasted and that our energy is invested in delivering the most valuable work for the product owners and stakeholders.
As a team, you will learn how to plan the most valuable items for each sprint and what number of items represent the perfect balance between quality and speed of delivery.
If you like the idea of mentored and coach-driven skills development, visit our Agile Coach Academy page.
If you find that you need to develop your coaching skills to become a better facilitator and scrum master, visit our on-demand Introduction to Coaching course page.