Everyone these days who works in an IT shop has heard of Planning Poker, or sometimes known as Scrum Poker, the process during Sprint planning where the team members take an educated guess as to the effort required to complete a user story. The definition of effort in this case, to prevent heated debates, lets assume is simply a measure of time.

There is one key point that I remember learning during the Professional Scrum Master course was what facts the team should take into consideration when playing poker.  For example, on projects starting from nothing except a number of somewhat fleshed out stories from a full backlog, most teams may perform something called an Affinity Estimation.  Affinity Estimation is the process of sorting those stories (usually on index cards) in relative order according to effort.  So as the team sticks stories up on the wall, white board, or tabletop, they place them somewhere between other stories or perhaps on the same axis as other stories which they think requires the same effort.  They may also put those stories either to the far left (least effort) or the far right (most effort).

Any team with experience using this method of estimation knows that when all the stories have been “estimated” they will be grouped into their relative points.  The stories to the far left will be 1 point, or perhaps 2 points to leave room for potential future stories requiring even less effort. And the stories at the far right will get assigned either 8 or 13 points.  Thirteen is usually that borderline size that begs the question, “Is the story too large and need to be broken down?” Some other teams, may use a larger range of values particularly if their sprints are 3 or 4 weeks long.

Here is one of the key points I want to mention, anyone with enough experience working with points will know that often there are very similar stories that could potentially share some of the same required development to meet the definition of done. During Affinity Estimation you don’t really care about that, those similar stories will all get the same point since they essentially share the same effort.  And ideally during the development process, you should see a natural rise in velocity from sprint to sprint simply because some of the stories being developed in spring 8 may have had a similar story completed in spring 7, and another similar story in spring 6.  So as more and more of the same code required by all those stories is incrementally developed, velocity should go up.

But where this really becomes an issue is when the client decides that they need to add a bunch of new stories. That’s great, more work for us. We have our prime story that we’d defined 12 sprints ago, so that can help us estimate.  Of course, the team has been neck deep in code for those 12 sprints so they’ve lost the appreciation of effort required to complete the prime story when everything was new. And so it becomes often difficult to do a relative sizing between a long forgotten story with recent hands on experience, so most team members revert back to a gut feeling based on experience from the most recent stories completed.

But the even bigger issue is that someone always dictates that the effort required to complete the new story should take into consideration the development that’s already been completed by the team in previous sprints; the new story point should be lower than similar already completed stories because some of that work has already been completed.  This sometimes results in a short debate about one’s Scrum religious beliefs.  And if this had been in the wild west, it would most probably have involved some bottle throwing, smashing of chairs and fist fights.

But because we’re in the 21st century, and also because of the nature of Agile and in turn Scrum, I have always believed that the team should never look beyond the current sprint when planning and working. Every sprint should be a short term effort to produce a deliverable. And every new story should be assigned a point as if it had been part of the initial Affinity Estimate.  This can always result in a spike in velocity in certain sprints simply because some stories took less effort than expected.  But that is the spirit of agile.  Most think that Agile is there to benefit the client, but it also benefits the programmers, because they are not tied to a predetermined time estimate.