Allocating Capacity for Backlog Refinement.

In my opinion the answer is as much as needed.  The word "usually" implies that there may be times that they need more and others where they need less than the 10% rule. Ask the Team how much time they feel they need to refine the Product Backlog Items in question.

In my opinion the answer is as much as needed. 

If the team spent too much time doing refinement, wouldn't that be an issue?

Wouldn't it be better to be able to calculate a certain amount of time and try not to go over that threshold?

What is the maximum time (ideally speaking) these Development Teams can spend for Refinement?

A team is expected to use up to 10% of its Sprint capacity for refinement. How team members work out capacity is entirely up to them. Their estimation method could factor in effort and complexity, for example. Hence there is no ideal maximum time for refinement at all.

@Steve 

If the team spent too much time doing refinement, wouldn't that be an issue?

Yes, it is an issue if it is consistent.  If it is an occasional thing, I don't get too concerned. I coach the 10% as a target but make sure that it is understood not to be a hard set limit. I find that when a team starts working on a new problem space or new technology, it sometimes takes more refinement than when working on something very familiar.  Refinement is only really beneficial when it results in better understanding of the work.  If the team doesn't do enough it isn't as useful. 

Hence there is no ideal maximum time for refinement at all.

@Ian Mitchell, @Daniel Wilhite, I guess I poorly phrased the last part of my post. I agree that there is no "ideal maximum" time and that sometimes refinement efforts can take more time.

What I was trying to achieve by posting the question and the numbers is to see how "10% of the capacity of the Development Team" is calculated.

The capacity of the Development Team to me is one of the following calculations:

1. 9 Developers x 6.5 Hours/Developer/Day x 10 days in a Sprint = 585 Hours (Total Capacity of Development Team); 10% x Total Capacity = 58.5 hours

OR

2. 10 Days = Capacity; 10% x 10 days = 1 Day = 6.5 hours

What is capacity then? The number of days available in a Sprint? The sum of the hours of the total availability of the developers in the team per Sprint? Or is it the Velocity?

Using the numbers and Teams above what is the 10% capacity of those two teams? What is the capacity of the above teams?

I coach the 10% as a target but make sure that it is understood not to be a hard set limit.

@Daniel Wilhite, what is the 10% target? It must be some value, either days, hours, velocity... right? I also assume capacity is a variable each Sprint. So how are you calculating capacity?

My understanding is that it is the capacity of the whole team. So your 58.5 hours would be the number to use.

I tend to agree with Daniel Wilhite here.

When I'm talking to a team about effort in refinement, I'll look for between 2-4 hours per Development Team member per week of Sprint. Based on some of the more recent productivity data that I've seen, 2 hours is probably a more realistic goal based on how long people actually work for. I also tend to just stick with one number - I'll ignore holidays, vacations, and other intermittent activities. If there regular events that occur during a Sprint that take half a day or more, such as a company that implements '20% time'. That's what I usually give as a target idea for teams.

If I'm concerned about a team, I may retroactively look at self-reported time spent in refinement activities and actual hours worked (perhaps taking into account a scaling factor for productivity) and see how they stack up. If it's significantly above or below 10% for several (3+) Sprints, then that may lead me to asking questions about the state of the Product Backlog.

In your specific cases, I'd present the team with the idea that they should think about spending between 20-40 hours per Sprint on Product Backlog Refinement and consider this in planning. Now, how they allocate this may be up to them. For example, they need to do an architectural spike which is extremely in-depth and involves research and building a prototype - perhaps one or two people will use a day or two (maybe call that 24 hours - 16 hours from one person, 8 from another). The rest of the 7 members may spend an hour on other refinement work, bringing the total up to 31 hours. That's well within target.

The best judge of the effectiveness of refinement activities is the Product Owner. The Product Owner is responsible for "ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next" - is the Product Backlog sufficiently refined to give Stakeholders a vision of what the near term future is likely to look like, provide feedback, and suggest ways to adapt it to better serve their needs and add value?

In your specific cases, I'd present the team with the idea that they should think about spending between 20-40 hours per Sprint on Product Backlog Refinement

@Thomas Owens, How did you get the number 20-40? Was it based off of Team 1 or 2 per the example?

Not to complicate this further. The only thing I was trying to understand, and my only ask is how is the capacity of the Development Team calculated, and what is the 10% of that. Is it possible to illustrate with examples?

My question is as simple as observing the speed limit when you drive, How would you know if you are 5 or 10 miles above the speed limit without a speedometer or knowing what speed your currently travelling at?

I am trying to establish a value that can be used strictly as a threshold to know if we are utilizing too much time, I am not saying that you cannot spend more time but at the same time it would be nice to know if we are going over a certain limit. The idea is not to penalize any team or person but the idea is to learn and adapt if necessary.

How did you get the number 20-40? Was it based off of Team 1 or 2 per the example?

Both. Like I mentioned, I don't count one-off holidays and short absences. When it comes to refinement effort, I look at trends over multiple Sprints, so if it's low for one Sprint because of holidays and absences and a focus more on planned work, that'll just come out in the wash. I would only include things that are recurring every or most Sprints when looking at the team's total capacity in terms of hours.

Not to complicate this further. The only thing I was trying to understand, and my only ask is how is the capacity of the Development Team calculated, and what is the 10% of that. Is it possible to illustrate with examples?

For me, it's simple. Assuming everyone works the same schedule, I take the number of working hours (not productive hours) in a week and multiply that by the number of people on the team. That's maximum productive hours, assuming 100% productivity. That's not realistic, so I then take a portion of that. I've found 50-60% to be a good number, unless I know the organization well. The range between that lower bound and upper bound is for the team, as a whole, to spend in refinement. If they go under or over for one or two Sprints, no big deal - it happens for any number of reasons. But if they are going over or under for 3+ Sprints, I start to ask questions. There may be good answers and it's not a problem, or it could be a sign that the team isn't spending enough time in refinement.

I am trying to establish a value that can be used strictly as a threshold to know if we are utilizing too much time, I am not saying that you cannot spend more time but at the same time it would be nice to know if we are going over a certain limit. The idea is not to penalize any team or person but the idea is to learn and adapt if necessary.

You really can't do that. You can set alarm thresholds, but it's hard. My threshold is 3 or more Sprints outside of the range I described above, just because it makes sense to me and has worked for me in the past. There are others. Maybe spending 20% or 25% or more of capacity is a flag. Or maybe spending under 5% is the trigger. Maybe all of these are triggers.

Aside from effort spent in refinement, I think the best measure is the opinion of the Product Owner. The Product Owner is accountable for ensuring that stakeholders have visibility into forthcoming work. Does the Product Owner feel that the Product Backlog is sufficiently refined to give them and their stakeholders insight into the near future of work for the Development Team based on what is known today? If the answer is yes, then refinement is sufficient. If the answer is no, then the team should work on refining and providing clarity into the Product Backlog. This is very context sensitive.

Now, the last part to this question is should capacity measured in Hours, Days, or Velocity? I've seen variations using all three. When velocity is used, the team essentially creates a placeholder story with the respective points for refinement.

Any thoughts or opinions?

I take a different tact than @Thomas.  Again I refer to the "usually" in the description of refinement.  I have no hard and fast line I draw for the amount of time.  Instead I observe the team and if I see them spending more time refining than building it raises a flag to me.  I then analyze the work they are doing compared to the Product Backlog Items that they are refining to see how much it has actually changed in the time they spend.  As I have said, not all stories are created equal so some may take more time than others.  I admit to using circumstantial evidence in this but every time I have brought it with a team, they usually agree with me from the start of the conversation.  If you can observe it, then there is a good chance that they feel it. 

One to remember is that refinement can occur in many ways. Spikes to learn more, meetings to discuss, exchange of comments in a user story (assuming a tool is used), chat in systems like Microsoft Team or Slack, discussion between 2 or more people at their desks.  In addition many companies do not have any time tracking mechanisms in place which is almost every company I worked in software development.  The exception to that is when working some kind of time and materials contract. And my experience has shown that in those situations the reporter often exaggerates their time. That is why I fall back to observing over gathered data. I can do that regardless of what data is actually being collected.

I know it isn't a formula that can be used but it has worked for me and fits empiricism in theory. 

Now, the last part to this question is should capacity measured in Hours, Days, or Velocity? I've seen variations using all three. When velocity is used, the team essentially creates a placeholder story with the respective points for refinement.

Hours, usually. But I try to deal with percentages rather than time.

I typically compute a team's full capacity as (8 hours * days in a Sprint * Development Team size). This is "100% capacity" or "full capacity". Of course, this is also extremely optimistic and I recognize that. If you need to be more conservative, you may want to use 6 or even 5 hours as a baseline for full capacity. I only use it for quick sanity checks against both Sprint Planning and refinement.

If capacity is reduced, I figure out what the number of hours the team will be working. Again, I tend to use 8 hour days and consider a half day off to be a full day off. This just makes math easier. I don't use this number for refinement activity, though, since I don't tend to look at a particular Sprint, but a rolling window compared to full capacity.

If you want to capture the historical data, you can record true capacity at the end of each Sprint as well. The level of precision needs to be driven by how you are using the data. For me, I just sanity check, so I don't need a whole lot of precision. If you are driving planning and tracking work in more detail, you may need to be more precise.