4

When I read about story points it is always mentioned that they should be used because they are a relative measure with examples like:

It takes me 60 minutes to run a trail while you only take 30 minutes to run it. So time is not a good measure to communicate the effort. Miles would be a better choice because a third party could then estimate their individual time based on their own speed.

However you could just as well do the same with time estimates. I say it takes me 60 minutes and you know that you are twice as fast so you can conclude that it will take you 30.

Story points: time = storypoints / individual velocity

Time estimation: time = basetime / individual velocity

So what is the difference and why should I use story points.

EDIT:

It is also mentioned that story points are relative since they are assigned in respect to a reference story. However you can do just the same with time. I.e. Reference story A is assigned 1 base hour instead of 1 story point.

So the advantage of story points as I see it is simply this concept: Don't give a ballpark figure, but rather estimate in relation to a reference point. But as soon as you assign a measure to the reference it does not matter if it is points or time. The result is the same.

|improve this question
  • 2
    Your example only works if I know your speed, I can't use it if I know mine. Even if the distance is the same, your estimate is worth nothing to me until you calculate or relative speed. The interesting thing is, that if your team gets faster over time, or maybe adds a number of things to their definition of done, the distance remains the same, yet their relative speed changes. Hence the original estimate in time is no longer trusted. But if you had kept the distance, the new speed would allow you to quickly forecast without having to recalculate all values. – jessehouwing Dec 3 '16 at 16:29
  • Plus, most people tend to be very bad at actually estimating in hours. Especially if things are more than a couple of hours worth of work. Reality happens ;). The relative estimates help individuals and teams learn their capability iteratively without having to constantly re-estimate their work. Their velocity will provide an indicator to make predictions, even though a velocity can't be trusted for (long term) predictions. – jessehouwing Dec 3 '16 at 16:35
  • @jessehouwing The time can be used relative just as well. If a user story is estimated as 1 point or one hour does not matter. The hour does not refer to the time I actually need for it. Think of it more like a standard man hour. If I am new to a topic I may just double the estimated time. So instead of having a velocity measured in points you have a velocity in standard man hours. – Chris Dec 3 '16 at 17:10
  • 2
    True. But many people have difficulty understanding that 1hr estimated is not 1hr in the real world. That there actually is nobody in the org that can actually do 1hr estimated in 1hr. It's a trigger for the mind to consciously understand the difference. – jessehouwing Dec 3 '16 at 17:34
  • 1
    Measure it however you like, as long as it's relative. But as @barnaby points out well below, trying to explain "relative hours" (i.e. hours that aren't hours but are called hours) to someone that's not you (especially a client or management) will not go well. – dKen Dec 14 '16 at 8:04
5

In Scrum we do some work in a time-box and then measure how much work was completed.

Now you could estimate stories using time units. But that would make for some strange results:

The team completed 10 days estimated work in 15 days.

Probably better to use a measurement that has no time units. In fact, when you think about it, the units we use are completely irrelevant.

That is why we use story points. They are arbitrary units.

The team completed 10 story points in 15 days

Now the team repeats this process for a few sprints and then calculates their velocity:

We average 12 points per sprint, so that is our velocity

As long as the team stays consistent with their sizing of stories, then this velocity is a useful way of predicting the capacity of future sprints.

Note that the team's performance may change over time. So we continually recalculate the velocity (often using a rolling average).

The important thing to remember that we are not estimating how long it will take to do work. Instead we are sizing work and then measuring how long it took to be completed.

|improve this answer
  • 1
    Excellent answer. Abstract "sprint points" allows for calibration of team estimating and decoupling estimation to the day/hour. I would also note that larger sprint point estimates imply more uncertainty of the actual size. While breaking user stories to smaller sub-stories or into tasks help mitigate ambiguity, saying the destination is 10 days away implies same precision as 1 day away. If your brain automatically translates sprint points into hours or days then think of T-Shirt sizes (s,m,l,xl). One XL story can take significantly longer than another XL story. – Zephan Schroeder Dec 6 '16 at 7:13
  • Hits the nail on the head. Just thinking about trying to explain 10 days estimated work in 15 days to a selection of my clients makes me very uncomfortable! – dKen Dec 14 '16 at 7:58
  • Good answer. I just want to add some my thoughts as follows: Firstly, do not concentrate on what story point is. it's just a unit for measuring weight of user stories in order to ensure that work in a sprint does not exceed team's ability. Secondly, estimation by story point is easy and fast so it is proper method for using in a sprint planning meeting. – Linh Dec 14 '16 at 8:04
  • If you want to get safety on story point estimation, you can find out yourself how many hours spent for one story point and estimate in-hour effort based on that. – Linh Dec 14 '16 at 8:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.