Story Points mean effort but not time?

Question

In Scrum, team assigns story points to tasks during planning poker. When explaining the meaning of points, the scrum master says it is effort. So if it is time consuming task but can be done easily or it is a complex task but can be done fast they all can have the same points. So the intention is to forget about the time units and play with effort units. But in my opinion it is not fair. Why? Let me say how many concepts connected with points play as time.

1. After several sprints team already know how many points it can complete during one sprint. Sprint duration is fixed - say two weeks. Hence if you find your velocity say 200 points per 2 weeks then you know that the team speed is 20 points per day. Which generally means that one task which has 20 points should be done, ideally, in one day. Hence 20 points means one day. And one day, is, surprisingly, time unit not effort. If you asses by effort then you might finish it in 2 hours and you will be ahead of your sprint which is not good (wrong estimation).

2. Burn down charts connect points to time as well. So as in the previous case, we again can think about points as time. Otherwise, we will get ahead or behind of the sprint schedule.

3. Team very soon identifies with time units, probably because of 2 previous reasons.

So why we say points are based on effort and are not connected directly to time if, indeed, they are meaning time? What is a problem to say X points is Y time for team A and Z time for team B?

Answer 1

Story points are designed to deal with the inherent uncertainty

If you toss a coin you will get heads 50% of the time. If you toss the coin a large number of times the actual % will tend to get closer and closer to 50%. However, you cannot tell whether the next toss will bring heads or tails.

In the same way, team velocity tends to average out to a certain number over a period of time. But there is no way to tell what precise number of points a team can accomplish in the next sprint.

By using hours instead of story points you are sending the message that you can tell whether the next toss will bring a head or a tail (how many hours of work you can accomplish).

Here are 3 more reasons why you don't want to use hours:

1. Human beings are better at relative estimation than at absolute estimation. You can see references to research on this in a prior thread here.

2. Story points avoid endless arguments among individuals who perform at different rates.

3. Physical measurements such as hours have emotional baggage attached with them. For example, I have seen some managers do an analysis of estimated hours vs actual hours and use that result to make up their mind how well a team is doing and how individuals within the team are doing. Story points are designed to avoid such misinterpretation of estimation.

Answer 2

The best analogy for points is distance. Think of points like a distance between two cities. Even though everyone agrees on the distance, different cars/drivers will complete the drive in different amounts of time.

Similar to distance, points are supposed to be absolute. So an expert developer and a beginner both agree that a story is 20 points, yet the expert may be able to complete those points in one day and the beginner in two days.

A team's velocity is the total points completed in an iteration. It is appropriate to use velocity (either of a developer or of the aggregate team) to convert points into an estimated completion time (points/velocity=time). It is inappropriate to think of points as a direct measure of time.

See Mike Cohn's article on the value of story points for a longer and possibly clearer explanation of the concepts I've summarized here. Mike Cohn is a founding member of the Scrum Alliance and one of the top authors on Agile. His book, Agile Estimating and Planning, is another great resource.

Answer 3

So why we say points are based on effort and are not connected directly to time if, indeed, they are meaning time?

Because Scrum does not really works with time. The smallest delivery package is an iteration backlog - fixed time -, therefore it does not matter how much time a team needs to deliver a point. What matters, is that the team delivers its commitment: the iteration backlog. The team's speed - that has the time component - is based on the iterations. Different philosophy.

What is a problem to say X points is Y time for team A and Z time for team B?

Because the points are not comparable and not even for the same team. If a team learns, after several weeks the same task will get less points, although Scrum Masters advise do not use less points. They argue that the task is still complex/complicated so it worth the same as before. Nevertheless, points are relative to a certain state of a team, therefore not good for any comparison.

However, you can make it absolute by checking how much of their commitment the teams delivered, but this is a different topic.

Answer 4

All about using points instead of units of time is to measure the complexity of the task and not its duration. Naturally people are used to think in hours/days and while measuring tasks in these units they make some assumptions that are often wrong.

Mature development team thinks in terms of how this task is complicated. Do I need additional resources to finish it. Can anything prevent me. The greater the complexity, the more points you have. If the scale of the task is large, it tends team to re-think it and divide it into smaller tasks (not necessarily shorter).

Often the task valued at 40 points will be done faster than the task valued at 8 points, for example if you had to wait for something else to finish it. This does not change the fact that the first task was much more complicated.

For you, it's important that the whole team has a certain velocity and is able to burn a certain number of points in a given time. Then you know how many points team can potentially burn per sprint. And every member of the team must be convinced of the complexity of the task (not its duration). Then this whole mechanism works as it should.

Your attitude is a common problem in the transition ftom hours to points. If you don't change your approach and do not check how it works, no one on this forum won't convince you that this is good. Most developers have a big resistance to change thinking about the tasks, but after a while working with points, they say that it is much more natural and they refuse to come back to units of time .