# How do you measure time units in sprint velocity?

I am trying to get my head around "Story points" using the Scrum methodology. As a starting point, I have been following the following article:

http://scrummethodology.com/scrum-effort-estimation-and-story-points/

With my team we are using the t-shirt sizes (S, M, L, and too big) approach. Using this approach, how do we quantify the time for each user story?

Is doing:

• S = 1/2 a day (maximum)
• M = a day (maximum)
• L = 2 days (maximum)

a good approach?

• You don't quantify time - that's the whole point of using T-Shirt sizes. If you're going to equate them to time then you may as well cut out the obfuscation and just use time estimates.
– mwan
Commented Nov 5, 2015 at 22:48

## Story Points Are Never Time Estimates

Is doing:

• S = 1/2 a day (maximum)
• M = a day (maximum)
• L = 2 days (maximum)

a good approach?

Absolutely not. Story points measure complexity and the level of effort required to complete a feature, including the team's Definition of Done. It is not, and should never be, directly mapped to units of time.

## Story Points Measure Complexity/Effort; Tasks Measure Time

During the second half of Sprint Planning, user stories from the Product Backlog can be decomposed into tasks for the Sprint Backlog. The common rule of thumb is that Sprint Backlog tasks should be approximately 0.5 - 2.0 days in length so that it is easy to determine if a task is "done" or "not done" during the daily standups, but the user story itself is never mapped onto a unit of time.

Velocity is a metric for determining capacity for the current sprint. So, while it is reasonable to ask whether a given story can fit within the time box of a single sprint, this is really a capacity question rather than a time conversion. Note that some experts suggest that a single story should never exceed 50% of the available capacity for a time box, but the Scrum framework itself allows a single story to take up to 100% of planned capacity. Your mileage may vary in this regard.

• Thanks for this, the trouble that I am finding that if I am working with sub contractors who charge by the hour (or if I have deadlines) - how can I organise my sprint plan around this? I have also found that every feature is very different, and there have often been occasions where they have been under estimated by my team once they dig deeper into the story. Commented Nov 9, 2015 at 10:26
• You have a fixed number of hours in a sprint. You choose to commit to the next sprint or not. Commented Nov 18, 2015 at 20:54
• Generally speaking, if you have dated deadlines, scope (or some would say budget, but that's much tougher to apply effectively) needs to be flexible. For the underestimating, a low-impact/initial mitigation strategy is to simply measure the difference over a few sprints and then factor it in; if you commit to say 100 points (or a sum of shirt sizes) but end up finishing 80, 60, and 90 points because of emerging unknowns, then you should probably adjust your true velocity to their average (or avg - 1 std deviation). Beyond that, you could track sources of emerging points to discuss in retros. Commented Nov 19, 2015 at 19:49
• Absolutely resist create SP to time formulas. My advice would be to build in flexibility into your contract with the contract developers such that you can observe the rate at which they can deliver valuable software to you. Once a pattern of stable delivery emerges, then you may be able to use tools like the Velocity Range Calculator to build time range estimates based on empirical knowledge: mountaingoatsoftware.com/tools/velocity-range-calculator Commented Jan 29, 2016 at 20:11

As CodeGnome says, you don't want to quantify time, you want to abstract the effort and then use it as "velocity" - measure several sprints' points completed, then use it for planning purposes.

Relative sizing among the values is also important, such that something with a point value of 3 is about 3x the size of a 1, or 1/3 the size of a 9. Without relative sizing, your iteration velocity will vary widely depending on whether you do a lot of small stuff or only a few big things. Try going through the backlog and looking for stories that feel like they are "in the middle" size-wise, or of average size, and use that as your middle value (such as 5 on a scale of 1 to 13). Then simply bucket the other stories as bigger or smaller, and in a final pass, how much bigger or smaller. After a few estimation sessions it becomes much easier due to familiarity and an ever-growing list of completed and sized stories that you can use as reference ("triangulation" if you will).

The relationship between points and hours is a distribution. One point equals a distribution with a mean of x and some standard deviation. The same is true, as well, for two-point stories, and so on. While there might be some overlap in elapsed time between 1 and 2 point stories (some one-point stories might turn out to be bigger than the team thought; some two-point stories end up being smaller), or between 2 and 3-point stories, there will rarely be any overlap between a 1-point story and, say, a 13-point story in terms of actual elapsed time. With all that being said, I caution you against formally relating points to hours. You run the risk of forgetting that each team’s mean time to completion will be as different as their idea of what constitutes a point. Points are, after all, a relative measure.

Imposing an arbitery maximum is not going to work as there is such a large standard deviation between estimations at each point/tshirt size. That SD is the very reason that we use relative effort estimation instead of making up a number of hours that will be wrong anyway.

Now if you are working with third parties, or contractor's then you need to think in sprints. If you have a fixed length sprint, and fixed number of people then you have a fixed cost for you Sprint.

The thing that then varies is the velocity, or the amount of delivered functionality, in each Sprint, or done increment.

I guess you might know your budget going in, and you can decide the budget by the sprint cost and see how many sprints that you can fund.

You set the team to delivering at a sustainable pace and each sprint you have working software. You can stop at any time, and you can ship once you are happy.

If you are unhappy with the velocity then you need to deal with that. You could add more teams, make the team bigger, or stop development.