2

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?

  • 1
    Just as an aside: you probably don't want to be using story sizes as high as 40 or 100. I know these are in most commercially-produced planning poker card sets, but to be honest I think you'dbe better off throwing them out. Stories that big are hard to estimate accurately - even to within a factor of 2.5 - so benefit from splitting before estimation. – Jules Oct 29 '15 at 5:25
  • I have read several times now that the estimates 40 or 100 basically are just strong indications of user stories that need to be split. Good point, I will treat them as such. – tizenegy Oct 29 '15 at 5:31
9

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.

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.

  • Regarding question 1: What would be a good technique to provide a common frame of reference? Maybe use one of the items from the last session and use it as a starting point for all new estimates? – tizenegy Oct 28 '15 at 21:54
  • 1
    Using one of the items is probably a good idea. There may be many reference points for many task sizes taken from any session. – Maciej Chałapuk Oct 28 '15 at 21:59
  • 1
    @tizenegy: A good technique for the common reference is twofold: 1. Before (or at the start of) the first poker session of a project, the team selects a reference story that would be worth 3 points and it is given that number. 2. In each poker session, the team members keep the selected reference story and the recently estimated stories in mind when giving of their estimate. Those recently estimated stories should, at least in part, come from previous sessions, but they don't have to be the exact same set for everyone. – Bart van Ingen Schenau Oct 29 '15 at 7:55
2

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.

1
  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.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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