Identifying and considering the important factors to calculate a persons Capacity for a Sprint?

Question

My team works in a 3 Weeks sprint, and accordingly we calculate the capacity of Team member based on his or her planned holidays and company Vacations.

But we cannot deny any unplanned / Sick leaves, Unplanned meetings and Training. Different Inter & Intra team communications which may be important for my own project or other teams. Knowledge sharing is an important core value of a growing organisation that encourages open cross team interactions.

Different Sprint Ceremonies also take some time of the team members during these 3 weeks. What points are important to be considered calculating the Capacity of the Team members considering they spend 8 hrs in the office.

Answer 1

I'm deducing that your team uses story points for an initial estimation then, at the planning meeting, breaks stories into tasks and estimates them at the hour level.

First, some general suggestions:

1. Never schedule 8 hours a day. Interruptions happen. Only schedule about 6 hours a day for development tasks.

2. Make sure you're removing those planned days off from the team's capacity. Likewise, be sure to remove known meeting times from the capacity as well.

But you seem to know that already. You want to know how to handle unexpected absences.

1. Leave some slack in your planning.

   We humans are really bad at estimating. Things usually take longer to do then we estimate they will. Leaving a bit of slack in your schedule allows you to absorb both the bad estimates and some absences. If the team does meet their iteration goal early, then they have some time to pay off some technical debt.

2. Accept that any given estimate will likely be wrong and you won't always get all the stories done, even if every one shows up every day.

   Basically, don't worry about it. Take some time to remember that developers are people, that you're a person and not code generating machines. Embrace the uncertainty of software development and find ways to be flexible. Can we drop a story from this iteration? Joe got his tasks done early, can he pick up Susy's while she's out? Can we extend this iteration another week? Learn to be flexible (dare I say, agile) and react to the unknown with grace.

   So, you failed to deliver every story in the iteration? Big deal. It happens. Bring it up in the retro, let the team talk about why and how they can lessen the impact of unplanned days off. They'll have way better ideas than strangers on the Internet.

3. Stop doing hour level estimation.

   It's largely a waste of time that generates a false sense of knowing, in my personal experience. Instead, use the historic number of story points completed as your team's capacity. In any specific instance, it will be wrong, but so will the hour level capacity planning. Sometimes they'll get more done, sometimes less, however on average it's a pretty good indication of how much the team can accomplish in an iteration.

   The goal isn't raw throughput of tasks. The goal is an iteration of working and valuable piece of software. Do the most important thing first, and you'll have that whether or not someone on the team gets sick for a few days.

Answer 2

The Scrum Guide says this on the things to take account of when determining the commitments for the next sprint.

The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.

The most important thing to take account of is the actual evidence of the work you've achieved in the past. The measure of how much your team can get done in an iteration is typically called Velocity.

It doesn't matter whether team members are there for 8 hours. It doesn't matter that sometimes there are meetings. We aren't individually interested in these things, and it's much better to directly measure the thing we do care about, our velocity.

Note that the Development team is responsible for deciding commitments (not the scrum master), and that performance is measured as a team, not as individuals.

While the Scrum guide leaves the "How" the development team estimations stories an exercise for the reader, most successful teams use something like Story points.

For example, lets say my team has a few stories of size (in points, left is highest priority) { 1, 5, 8, 3 }. If last sprint, we managed 6 points, the team knows to take on 1 and 5 only. If we managed 9 points, we know I can take on 1, 5 and 3. The thing powering the team's decisions is evidence from previous iterations. A "point" is not linked to any amount of time other than through our evidence based measure of velocity.

Teams that use hour estimates in practice don't make good use of velocity and therefore plan poorly.

So to summarize,

• Estimate stories in points rather than hours
• Measure the Velocity of the team and use that to decide how many points to commit to
• Make sure the development team is making these decisions, not you

Answer 3

TL;DR

Estimate your team's capacity as an aggregate range based on historical performance, rather than as a sum of the ideal hours available to each individual. Furthermore, you should carefully consider what you hope to accomplish with such a calculation, and determine whether a more agile approach to productivity and statistical estimation might not be a better fit.

Estimate Team Capacity

My team works in a 3 Weeks sprint, and accordingly we calculate the capacity of Team member based on his or her planned holidays and company Vacations.

In Scrum, velocity or capacity for an individual is never calculated. Instead, you calculate the projected capacity of the entire team based on empirical measures of past performance, and expect minor variations in individual or iteration capacity to even out over time.

More importantly, while you can use various techniques to estimate ideal hours available to the team, this will not give you good predictability regarding the amount of work you can do in a Sprint. Unless it's your very first Sprint, you're much better off using relative sizing (e.g. story points) and estimating how much work you'll be able to accomplish in any given iteration based on empirical data about how much work the team has been able to accomplish in the past.

Ideal Hours

Even if you choose to use ideal hours rather than story points, you would calculate a team capacity. For example:

1. Make sure you include all elements of your Definition of Done in your definition of work.
2. Assume a baseline of 4-6 hours of useful work per business day.
3. Multiply by the number of team members.

So, a five-person team has 60-90 ideal man-hours available in a three-week Sprint. You could just stop there, and let statistical variation iron itself out.

As an alternative, you can apply a fudge factor to adjust for known issues in a forthcoming Sprint. For example, you might:

• Reduce total capacity by at least 20% if a member of a five-person team is on extended leave.
• Reduce capacity by 7-10% to account for a holiday in the middle of your upcoming Sprint.

Pragmatically, I tend to apply fudge factors for large potential drags on velocity, but generally ignore them for minor perturbations like a planned dentist appointments.

Solving Your X/Y Problem

It seems likely that your real problem isn't a lack of precision estimation, but rather than you are treating team members as individual resources and striving to optimize for utilization rather than throughput. While you didn't explicitly say so, the way your question is phrased at least implies that tasks are being assigned to individuals, rather than collectively owned by the team, and therefore the absence or reduced capacity of any member of the team can create bottlenecks or expose dependencies within your delivery pipeline.

Don't do that.

Instead, make sure that backlog items are owned by the entire team, and that the team is working collaboratively to complete stories rather than sequentially or in parallel. In addition, backlog items should be as independent of one another as possible, so that the inability to complete one due to resource or time constraints doesn't "halt the line" for other backlog items as well.

Even if you're not making the mistakes I just outlined, please take some time to really consider why you are trying to trace capacity metrics to the individual level, rather than taking the team-based approach that underpins most agile methodologies. You may be surprised to find that doing so is unnecessary, and even counterproductive, in many circumstances.

Answer 4

Try adopting the LEAN idea of 'waste'

Get the team to record their hours against tasks, meetings, admin etc so that you can work out exactly how much time you are spending on 'non work' tasks each week.

This will give you both an average percentage of 'waste' time which you can factor into individuals capacity AND enable you to identify stuff that you can cut out to increase capacity

Answer 5

Rather than trying to plan for unplanned meetings, training or sick days, schedule a set of hours each day for team centered activities, such as:

• pair programming
• code review
• integration testing
• security testing
• performance optimization
• merging branches

In addition, create a reserve story which captures a percentage of each team members capacity each sprint to handle foreseeable action items, such as:

• production bug fixes
• research for spikes
• build breaks
• SSL renewal
• Refactoring code
• Updating documentation
• Integrating retrospective suggestions
• Planning for the next sprint

References

• Agile Security at OWASP (pdf)

• Peer Code Review: An Agile Process That Works! | SmartBear Collaborator

• Nurse Absenteeism and Staffing Strategies for Hospital Inpatient Units (pdf)

• The Johns Hopkins Hospital Postgraduate Critical Care Residency for PAs