In the previous article, we spoke about Product Owners forcing capacity on the Developers, and now we are going to have a look at the opposite situation: the Developers are the ones taking work into the Sprint that is beyond their capacity.
Often, Developer teams have one or more members who like to take as many items as they can. If they can deliver them, good. If not, we're in trouble. This deviation is easy to miss, especially when the team is only just starting to work within Scrum. A high-performing member might be able to deliver all the items they pick up, but other members might be trying to push themselves to the limit.
Why would Developers take more than they can deliver? I can think of several reasons:
- External pressure – there is a lot of pressure on delivery and the Developer wants to meet the Goal.
- Internal pressure – one Developer might be dependent on another and they want to help each other out. Or maybe, there is a need to prove to others that “I can do it”.
- Capacity issue – the team does not really know their capacity, they do not understand the User Story well enough and underestimate the size of it or individuals do not consider the overall capacity of the team, just their own.
Ok, but what does all this mean? And how do you to get out of these situations?
- When there is external pressure, there is a need for the Product Owner and Scrum Master to work with the Stakeholder and the Team. It is necessary to explain to the Stakeholder the capacity of the Team, what is realistic and what is not.
Stakeholders will then (hopefully) be better able to see the progress in small steps in each Sprint, rather than nothing is finished, there are lots of open tickets and Developers are frustrated that they cannot deliver the desired increment.
It is necessary to explain to the Developers that if they repeatedly do not deliver the work they committed to in the Sprint, they will lose the Stakeholders’ trust.
- When there is internal pressure, it is necessary to work with the individual as well as the whole team. A healthy rivalry can help an individual move forward and improve their skills. But when we are in a toxic environment where there is unnecessary pressure placed on people, we have to find out why it is happening, how we can prevent it and perhaps if the team composition is correct.
- Despite being a Scrum Master, I always thought that it is much easier to work with numbers than with people. So for me, the last issue, capacity, is the easiest thing to solve.
Here, I would suggest performing a really thorough refinement. To some, it could look like a waste of time, but the Developers will quickly learn what to ask and how to speak about User Stories so that everyone will understand them. They will understand their complexity and be able to estimate them well. I know, the estimation is always just a best guess, but still, your best guess will be much better after you have the chance to discuss the User Story with your colleagues and hear their opinions on how to develop it. Plus, Tasks are a huge If you spend your time during the refinement to also create the Tasks, you are more able to see the whole picture of the User Story.
What do you think? Are you a bit closer to solving similar issues? I hope so, and I hope that you will come back because next time, the topic will be the last deviation: tasks not created.
Thank you for reading,
Have courage and be kind.