Capacity Tracking - Scrum Master or PO Responsibility

Why should it be the Product Owner or the Scrum Master who has the responsibility for tracking capacity? Why should each team member need to have their capacity tracked rather than the capacity of the Development Team as a whole? Why does the Product Owner need to have capacity as an input into Sprint Planning?

Capacity is only referred to twice in the Scrum Guide. Once, in the context of Product Backlog Refinement, the statement is made that refinement usually consumes no more than 10% of the Development Team's capacity. The second reference is in Sprint Planning where the projected capacity is used with past performance, the current Product Backlog, and the most recent product Increment to determine what work can be done in the Sprint being planned.

My thinking is that the Development Team should be ultimately responsible for determining what their capacity is for the upcoming, and therefore how much time to allocate for Product Backlog Refinement and how many and which Product Backlog Items are likely to be completed in the upcoming timebox. They may ask the Scrum Master for advice, assistance, or facilitation to understand various ways to determine or calculate capacity and make it an effective process. Ideally, the Scrum Master will have insight into techniques that have worked or have not worked, and, can combine those insights with visibility into how the team and organization works to make effective suggestions.

My first suggestion would be to understand the purpose of tracking or computing or projecting capacity and how that fits into and supports the various Scrum events.

Also PO should focus more on Product Vision, Backlog refinement instead of dealing with capturing capacity

That's a great starting point!

If we can agree that it is wasteful to have someone tracking the capacity of the people doing the work, perhaps we don't need anyone to fulfil this function.

Thomas gave a really good answer, and I particularly like his final sentence:

My first suggestion would be to understand the purpose of tracking or computing or projecting capacity and how that fits into and supports the various Scrum events.

What needs to be understood? From the general tone of the post, it sounds like you might need more predictability. If that's the case, there are techniques for improving that, either for a Development Team to forecast the current Sprint, or a Product Owner to forecast over a longer period.

We are using excel to track Team's capacity. Recently there was some confusion on who owns the responsibility of getting the capacity updated for the team.

Are the team incapable of estimating their capacity for themselves? If so, why?

I think this is because of management, management likes to know specific numbers or data that can tell them that this is what the team can worked on and they are very hard to influence on these kinds of situations. They want specific numbers so when the team did not meet it, there is something they can hold on to when appraisal or review comes in (I think this is reality to previous companies I have worked on).

Nitin, let me know if this is the reason as well on your side.

Thanks for your replies. We do use Jira but the Capacity Tracking module is not enabled yet. So we are using excel to track the capacity of each resource for upcoming Sprint - Which acts as input for Sprint planning. 

Why do you feel the NEED to TRACK capacity? What value are you getting from it?

I've seen teams go high-level and I've seen teams go so far deep into details that it is basically stretching every single hour that they possibly can to do more work. 

My team now does it at a high-level, basically just letting the team know what days they will be on PTO. We don't track by the hour or put such a crazy emphasis on that because it's not valuable and so easily weaponized. Our example is for Christmas time, people just put on the team calendar the days they planned to be on PTO, that's all the "capacity tracking" we do. 

"What value are you getting from it?" - None but some companies that have traditional management structures are very hard to explain that equating hours work over capacity does not yield better output or outcome. They still insist to have those numbers as a way to reason during appraisal or yearly reviews. I have different reasoning that they should need to check if the teams are working as what they are paid for and I stopped listening when they tell me this.

Working 8 hours day on your area, glaring at your monitor or pretending to do work is not effective way of creating outcomes or output. At some country or some companies which have time restrictions, it does not matter if you are just glaring at the monitor 9 hours a day (you will get full payment). They will value that rather than those who came 30 minutes late but delivered so many output (you have salary deduction). They said, it is the law (which I do not believe there is no way to change it)

some companies that have traditional management structures are very hard to explain that equating hours work over capacity does not yield better output or outcome. They still insist to have those numbers as a way to reason during appraisal or yearly reviews.

That's our job as Scrum Masters to help educate management, teams and other internal stakeholders, rather than accept such organizational impediments.

Working 8 hours day on your area, glaring at your monitor or pretending to do work is not effective way of creating outcomes or output. At some country or some companies which have time restrictions, it does not matter if you are just glaring at the monitor 9 hours a day (you will get full payment). They will value that rather than those who came 30 minutes late but delivered so many output (you have salary deduction). They said, it is the law (which I do not believe there is no way to change it)

It isn't always immediate, but those organizations that don't adapt, and simply accept such wasteful practices will lose their best staff, continue to deliver less value, irrespective of how hard people are working, and will eventually be vulnerable to disruptive startups, or a gradual decline in market share, as their competitors do adapt.

In increasingly international markets, local employment conventions become increasingly irrelevant, and the focus has to shift from keeping people busy, to the continuous delivery of value.

Of course, it is unlikely that a traditional organization will shift immediately, unless something happens to create a sense of urgency; but a starting point could be to supplement pre-existing working agreements with a focus on value delivered at a team level.

By asking the right questions about the effectiveness of the team, and encouraging the teams to resolve their own impediments (and ask when they need help), the issue of individuals staring at a monitor all day should disappear.

Ideally it would disappear by team members being more motivated; but if there is effective team accountability and with the right support, the team will be incentivized to help individuals who are struggling.

Ultimately, if it emerges that the individual is not working because they don't want to, then an empowered team can help make it clear that this person might need to move on.

@Sherwin, I fully understand that MOST (not some) companies still have traditional management practices and policies. That still has zero correlation to Capacity. All Capacity is is the total number of available hours a team has in a Sprint, what you're talking about refers much closer to time keeping. One of the main points of Scrum is that a team works as a single unit to produce an increment, it doesn't matter how many hours are spent actually at their desks writing code or walking around the office collaborating. Some of the best WORK that I've been able to do is through walking around with my team and talking rather than sitting at our desks staring at lines of codes and/or backlog items. As Simon said, the Scrum Master should be working with leadership to get them to understand that. 

My point of asking what value is received by tracking capacity down to every single hour of the developer's time is because that just screams lack of trust AND a leadership that thinks being busy equals getting work done. I've gone through countless sprints where the team takes in a ton of backlog items and are working like crazy (being busy) and at the end of the sprint, they don't have a done increment, none of the items meet the Definition of Done, therefore no value was received. Why? Because their leadership is so focused on seeing people BUSY. 

As a scrum master, I thought that formulating capacity is only helps to solve commitment issue in the team. In capacity-considered sprint planning, a team selects one product backlog item at a time by roughly identifying and estimating the tasks that will be involved, and stopping when they feel the sprint is full and commits each other.

I tried to help to team for considering how much value we delivered according our capacity. I'm using basic excel template for forecasting next sprint velocity, No plan is perfect we know, so capacity should  helps to team to fell they are in confidience. 

Nitin,

I would agree with you that the responsibility to calculate capacity should be on the Scrum Master - for now. I am scrumming for a new team who is not used to calculating their capacity, so during Sprint planning I ask for their days off for the upcoming sprint and quickly calculate their capacity in front of them (in Excel because we don't have the Jira capacity Add on yet). Once they get in the habit of this, the dev team should be able to calculate it themselves. The product owner is really involved with capacity planning. He/she is the visionary for the product backlog. 

Thanks,

Suz 

Correction: What I meant to say was: The PO is "not" really involved with capacity planning.

-Thanks!

Suz

My opinion will be same as Ian. The tracking of the capacity will be best managed by the Development Team. This will help them in gain experience in delivery of the product better. Scrum Master role is never to track capacity but if I consider your company environment which still undergoes Agile transformation, you could take up this task and demonstrate the proper way to do it as a leading approach so that the team has a rough idea what should be done in this area and how can they perform better in the upcoming sprints. Isn't it the capacity management is to do inspection of the team and to do adaption in the later sprints?

Thanks for the input as well, I've learned some inputs or ideas. I guess we were unlucky on those traditional management, their not keen or open on understanding that capacity and output are not linear.

I too have only seen the Scrum Master be asked (by management) to measure and track capacity.

Why should the responsibility be with the Scrum Master or event the Product Owner? Is it such hard math for individuals who constiute the Development Team to calculate on their own? These are highly skilled, talented, high functioning, highly paid individuals who are able to create a Product Increment through self-organization. Can they not do this by themselves in JIRA or Excel on their own?

Have we considered if the statements above have reduced their ability to nothing?

I say Scrum Master could do the capacity tracking. I already do the velocity tracking for four teams in my area. I'm a new SM and had a tough time deciphering between capacity, velocity and load. 

I like to research online to find situations that match mine and recently found 3 methods for calculating capacity. Purists and long-time Agilists will probably eat me alive for calculating capacity based on velocity but it worked. 

In my short amount of time on this Agile Earth, I have found the Manifesto words to ring true: "working software over comprehensive documentation" but also had a career before IT and had to document everything. I want everyone to get along so I bend to the management will and give them what they want. 

If your team is creating the right software for the client and your company is making money, do everything and anything you need to keep your team chugging along and keep management happy with stats. 

A SM has a ton of hats to wear but I've found you have enough time to do reporting that will help management see your team is doing right. That's your job right? Helping your team run agile, helping them build great software and help shield your team from management. 

Helping satiate management will help protect your team. Give them the stats. Cheers!

As a Scrum Master I do not track anything for my teams.  I respect the members to do what is right in order to deliver value.  In the few times I worked as a Product Owner, I did not track anything for the team for the same reasons.  As a manager (a role that I am currently in) I don't ask the Scrum Team for any kind of metrics for the same reasons.  In all 3 cases I am more concerned about the result of the work being done and what value it provides the end users which in turn provides value to the company. 

As a Scrum Master I do track things for myself to help identify coaching opportunities I have with the Development Team, Product Owner and parties outside of the Scrum Team.  But I keep those metrics to myself unless I see a need to use them in my coaching. 

As a Product Owner I track things for myself to help me know if I am maximizing the Product Backlog in such a way that it provides the Development Team with knowledge to make them most effective at producing value for the end users and ultimately the company.

As a manager I will track things to help me identify ways to coach my employees in becoming a better professional and to maximize the investment the company is making in the individual. But I never track how many hours an individual has sat in front of their monitor because spending 8 hours everyday in front of a monitor actually decreases productivity and as such means I am paying someone to be less productive than they can be which is very much opposite of my fiduciary responsibilities.