How to estimate accurate velocity when team members are on leave

Question

I am a Scrum Master of a team with 12 members. I know that the size of the team is large at this point, but as we grow further we will divide the team into multiple Scrum Teams. Our estimations for the User Stories are based on Story Points. For the tasks within a User Story we are estimating in hours. Based on the first 6 Sprints we were able to establish a team Velocity.

We did not have any issues in taking the User Stories, because we knew how many User Stories we could take for the Sprint based on our Velocity. When a couple of team members went on a planned leave, we were unable to estimate the number of Story Points we had to commit. Since we are not calculating Velocity per team member, we are unable to estimate how many Story Points we should take for the next Sprint. So, my question is how do we calculate the story points we can commit to the sprint when some of the team members are on a leave?

My second question is we are calculating the number of hours each team member is available for the sprint. As we should not directly map Story Points to hours, we are not seeing the value of calculating the number of hours for each team member during the Sprint Planning Meeting. How do we establish a relation between hours and story points?

Answer 1

TL; DR

1. Velocity is not a management target. It's an estimation tool, and you should be using it as one tool among many to help plan your Sprints. Don't treat velocity metrics as targets, or maintaining a given velocity as the primary goal of each Sprint.

2. Hours and story points have no direct relationship to one another. Story points measure relative effort, while hours measure ideal or wall-clock time. They are both useful, but are not interchangeable.

Estimating Variable Capacity

Velocity is a range, not a single value, and is generally most useful when:

1. Planning a project schedule once the velocity stabilizes.
2. Applying a smoothing function to spiky per-sprint results.

However, unless you've gathered sufficient velocity data to amortize variations in capacity, then you have to apply some common sense instead. Consider these examples:

• If you've been doing Scrum for a year, people take sick days, go on vacation, or work above or below their typical capacity from time to time. Velocity averages those data points over time, and allows you to make reasonable estimates anyway.

• You've only been doing Scrum for two months, and have had all hands on deck for both Sprints. You have zero data regarding normal variation, and no information on maximum or minimum team capacity. You will therefore have to apply a fudge factor.

It's Okay to Under-Commit

In Scrum, the main goal of Sprint Planning is to avoid over-commitment during a Sprint. The idea isn't to fulfill the 100% utilization fallacy; you don't have to pack each Sprint to the rafters based on your previous velocity.

The way Sprint Planning works is that velocity simply offers guidance, letting you know if you've gone over the reasonable work-in-progress limits for a single Sprint. It is up to the Development Team alone to determine how many story points can comfortably fit within the current iteration.

In your example, when you will be under-staffed for a Sprint, it is expected that the team will acknowledge this fact and adapt accordingly during Sprint Planning. For example, the team might say:

We normally try to limit our story points to 10-15 points per sprint. However, Bob is out having COBOL-based cybernetic implants placed into his cerebral cortex, so we should probably only commit to 8 points or less this time around.

The team then accepts only 8 points into the Sprint, based on their expected capacity. However, if they finish early, they can (and should) go back to the Product Owner in order to:

• Gather a few more small stories to round out the Sprint without over-committing.
• Ask the Product Owner for an Early Termination so that the Sprint Review, Sprint Retrospective, and Sprint Planning can be performed without simply waiting for the clock to run out.

The first is the most common practice, but the second is certainly acceptable within the bounds of the Scrum framework. It really just depends on what works best for your team.

Answer 2

Team velocity is a measure of team's past performance -- how much value they were able to produce in every sprint and it is measured in story points. Velocity is helpful to predict how many stories the team will be able to complete in the next sprint. However, velocity is not the only factor to predict this. Team capacity can be another factor. Lets take an example:

Your team has 5 members and the velocity is 60 story points per sprint. One member is on vacations during the next sprint. So the team capacity will decrease by 20%. Your estimated velocity for that sprint would then be 48 story points. 60 * (100% - 20%) = 60 * 0.80 = 48

This is an option that can be considered I guess.

Answer 3

Due to the complexity of a team, you'll never be able to calculate the Story Point / Person ratio. So, when you put together the Sprint Backlog use the User Stories from the Backlog and the capacity plan (this tells you how many people will be on board during the upcoming Sprint). You commit based on this data. The Velocity helps you not to overcommit in a Sprint. So it is not that helpful.

Based on your question you aren't using the estimated hours for anything. If your work is Story Point based, you won't need the hours at all. If it is possible don't try to convert Story Points to hours. They aren't convertible, like you cannot convert a horse to a bicycle. Both can be used for travelling, but there isn't any other similarities.

However, there is something you can try out, which may help you with your first question. If you estimate the hours for the tasks, you can sum them up and based on the capacity you can check if the sum fits your upcoming Sprint. For example, you have 2 User Stories. US1 has 2 tasks, and the sum is 48 hours. US2 has 3 tasks and the sum is 68 hours. Let's say that the 12 colleagues can do 120 hours in a Sprint. Without 2 you have only 100 hours, so the US1 + US2 won't fit into your Sprint. You can leave US2 out, or break it down to US2.1 and US2.2. I think this could work in your case.

Answer 4

I think you are using the velocity term in the wrong way, lets return back to the basic. The story point is a high level estimation of the effort needed to implement a story, used usually during release planning or pre-planning session.

Velocity is the total story points implemented during past sprint and this will vary from one sprint to another. Story points and sprint velocity then give us a guideline about the estimate stories to be committed in the coming sprints.

The task-hour estimation occur during sprint planning, it is a low-level estimation made to represent the actual effort in hours needed to accomplish all the requirements of a story.

Answer 5

To your first question, there is no scientific way of doing this. Here's a quick and dirty way.

Fraction of people on the team this iteration x the team's velocity. So if your team velocity is 10 and 1/3 of your team is out, 6 might be a fair forecast of what your velocity could be. Having a range would be better so maybe 5-8 in the above scenario. The value is in understanding the assumptions you used to adjust your velocity forecast.

Whatever you do, velocity is a tool that helps team members discuss and understand the work they are doing. So if team members are out and you're not sure how useful velocity is as a tool, just ask your remaining team members "Does what we are committing/forecasting based on our adjusted velocity seem reasonable?"

To your second question. Don't bother. Story points are distributions over time and shouldn't be used for capacity planning or reporting outside of the team. If you want to get into time-based agile methodologies your closest proxy will be lean kanban using cycle-time and its variance.

If you're not seeing value in calculating the number of hours each team member has available for each iteration, stop doing it :). Its very common for scrum teams to stop putting hour estimates on their tasks once they realize that velocity and consistent story point estimation practices are good enough for creating a forecast/commitment.