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?
In Scrum, are story points assigned at different planning poker sessions worth the same?
agile;project management;scrum;estimation
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.