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:
a good approach?
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.
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.
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.
