In Scrum, are story points assigned at different planning poker sessions worth the same?

Question

As far as I understand, a planning poker session usually is started by picking one item and assigning it a value (say, 1). This item will then serve as a reference for the rest of the session. From then on, all values will be relative to the first one.

Question 1: There seems to be no frame of reference to compare this session to past planning poker sessions, though. If the first item picked and assigned a '1' at session A is actually a bit harder to complete than the first item picked and assigned a '1' at session B, then points at session A and B will be of different value. This means that the total amount of points completed in sprint A and sprint B will not be comparable, defeating the whole purpose of estimation. Where is my mistake?

Question 2: Say the team uses the typical numbers (...13, 20, 40, 100). They decide that item1 = 20 and item2 = 40. Does this only mean item1 < item2 or does it also mean that item2 will take twice as long to complete?

Answer 1

Question 1: There seems to be no frame of reference to compare this session to past planning poker sessions, though.

There should be. Have your scrum master bring in one medium sized story from the previous sprint. You then have a reference point from which to start. When you point a new story, start by asking if the story is bigger than, smaller than, or about the same size as the story from the previous sprint. Use that information to size appropriately.

Question 2: Say the team uses the typical numbers (...13, 20, 40, 100). They decide that item1 = 20 and item2 = 40. Does this only mean item1 < item2 or does it also mean that item2 will take twice as long to complete?

It only means that item 1 < item 2. From a practical point of view you can maybe think 2 is roughly twice as big, but that's only a very, very rough estimate. It could be that an 8 point story is 10 or 15 times as big as a 1. As the numbers get bigger, the greater the chance that the estimation is wrong. This is arguably why waterfall fails us -- we try to estimate projects that are several months long. Humans suck at that, but we're pretty good at judging just a single day's worth of work.

For example, given a 1 point story, you are probably quite accurate on that assessment. It's hard to be off too far when you think the work will take about a day or less. However, if you have another story that you've pointed at 8 or 13 or 40 or 100 -- whatever scale you use -- you will be much more likely to be wrong. That is why stories should be kept as small as possible.

Answer 2

Question 1: There seems to be no frame of reference to compare this session to past planning poker sessions, though. If the first item picked and assigned a '1' at session A is actually a bit harder to complete than the first item picked and assigned a '1' at session B, then points at session A and B will be of different value. This means that the total amount of points completed in sprint A and sprint B will not be comparable, defeating the whole purpose of estimation. Where is my mistake?

It's better to have the same reference for each scrum session. Burndown statistics will be useless, unless points from all sprints are worth (roughly) the same.

Question 2: Say the team uses the typical numbers (...13, 20, 40, 100). They decide that item1 = 20 and item2 = 40. Does this only mean item1 < item2 or does it also mean that item2 will take twice as long to complete?

It means it will take roughly twice as long. It's just an estimate. It can take twice as long, it can take the same amount of time if it's overestimated, it can take 3 times as long if its underestimated, but it probably shouldn't take 10 times as long, or half the time of item1.

Answer 3

Stories in the backlog for the same team should be sized consistently, regardless of which planning poker session they were sized in. This consistent sizing is what permits the team to establish their velocity. A good habit for a new team is to identify the "typical" story of each size so you have a concrete reference when sizing up a new story.

As for question 2, the implication is that the effort for item2 is about twice as much as item1. Story size doesn't accurately correlate to the amount of time to complete although your team should develop a sense of how long a story of a particular size will take. As part of your retrospective you should review your point estimates, the actual duration and effort to implement the story, and feed that back into future planning poker sessions.

Answer 4

1. Depends on the team. In the past, I'm used to there being a general idea of what a single point was worth that was consistent across sessions. Of course, there is also something to be said for estimates getting a little better initially as a story may be estimated poorly in the first few sessions that after doing a dozen of them the estimates may be more accurate later. Your mistake is assuming that the frame of reference isn't there when it may be there, especially in the beginning for planning and computing velocity.

2. No, it means that item2 is approximately twice as complex as item1 and will likely require greater resources. The higher estimates can be fuzzier but can be a ballpark that would put it between what your statements are as if item2 was 100 that would also imply that it is going to take longer but also means it may be worth restating so that it isn't as large of a black box. The high estimates can serve as a warning that something has too many pieces to it in some cases.