Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Should I calculate capacity per team or per developer?

Last post 07:07 am May 18, 2022 by Filip Kosmalla
4 replies
10:00 am May 16, 2022

The team is using Story Points for relative estimations. They were doing pretty good without Scrum Master's support (they've delivered goals, managment is happy with the results), but what I've seen is some developers taking too much work on their own while others chilling for 1/3 of a 2 week sprint.
The team is very much data driven so I am working on a dashboard that we will use durign sprint planning and daily sprints to inspect SPs/developer. They are also aware of the situation and are happy to be able to adapt. 
What worries me though is that I've looked on Google to check how other teams are managing their capacity and it seems that 'per team' instead of 'per developer' is the right way to go.
Am I doing a huge mistake by inspecting SP/developer?

09:10 pm May 16, 2022

In my experience, if you start to measure story points by developer, the developers start to change their estimates to make themselves look better.  It will become a competition to complete more points than everyone else.  This breaks down team work and introduces siloed work efforts. 

A Scrum Team is a self-managed, self-organized group of individuals.  The completion of work is owned by the team not individuals.  That is why these statements are made in the Scrum Guide:

The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. 

My general stance is that the team is deserving of all accolades, not individuals on the team.  Team members should work together to get work to "done".  If your developers are assigning themselves work before the Sprint begins by "owning a story", then they are not actually working as a team who shares work.  It might be possible for more than one person on the team to do the same work but if the work is preassigned, that doesn't always happen.  For example, at the end of Sprint Planning Developer A has 8 items, Developer B has 6, and Developer C has 9.  Developer B finishes their 6 items by day 7 of a 2 week Sprint but since there are no other items, they sit idle for the rest of the Sprint.  At the end of the Sprint Developer C has only completed 7 of their 9 items. Now consider an alternative.  Each day in the Daily Scrum, each Developer chooses an item to work on.  When the work for that item is completed, they discuss with the rest of the Developers which item would be best for them to start on next.  This takes place every day of the Sprint.  Some days the Developers might decide not to start anything new and have more than one Developer work on a single item based upon new information gained the previous day. 

If I was on this team, I would work with them to realize that they may be doing themselves a disservice by following their current practice and see if they would like to experiment with other ways that could help them be even more productive.  But in the end, it is entirely up to the team to decide how they want to work, measure their work completion, and make visible the work that is being accomplished. 

01:25 am May 17, 2022

what I've seen is some developers taking too much work on their own while others chilling for 1/3 of a 2 week sprint.

That's the problem. The story point issue is just a symptom. What teamwork are they demonstrating? Perhaps the Sprint Goals they choose, even if they are met, don't give them enough reason to work together on a complex challenge.

06:29 pm May 17, 2022

In my experience, doing anything on the individual level moves the team's focus away from the whole-team to individuals. For example, the whole team commits to the Sprint Goal. So if you're using estimates and forecast capacity to check to see if it is reasonable for the team to commit to the Sprint Goal based on the amount of work associated with the Sprint Goal, then you'd want to look at the team's capacity and ability to get work done.

For me, I'd be curious as to why some Developers are "chilling" rather than seeking out the opportunity to pair with others. From what I've seen in the past, this usually happens when Developers feel that they don't necessarily have the knowledge or skills needed to help out. But pairing up can help them learn so they can be more effective in the future. Perhaps there are other problems, but understanding why there's not a team-centric focus on pitching in to help get work done would be my focus.

07:07 am May 18, 2022

Thanks for all answers!