Story Point Estimation is a “Relative Estimation Technique”. This is one of the popular estimation technique used in Scrum implementations. The meaning of Relative is that we assign a point value to each item. The raw values we assign are unimportant. What matters are the relative values. A story that is assigned a 2 should be broadly twice as much as a story that is assigned a 1. It should also be broadly two-thirds of a story that is estimated as 3 story points.

Why is Relative Estimation popular in Agile?

In the traditional world, the assumption was that the scope was clear. When the scope was assumed to be clear, it was possible to do bottom-up or absolute estimation. In the diagram below, we plan to do estimations which are more like the option 1 (Accurate and Precise)

In the agile world, the scope is unclear and every changing. In this circumstance the scope is arranged in a ordered (sequenced) list. The sequence list is such that the clearer items are at the top and unclear items are at the bottom. In this scenario, it is almost impossible to do estimations precisely. Therefore we go for option 3 (Accurate but not precise measurement). If we try to be option 1 (Accurate and Precise), we may end up with option 2 (Precise but inaccurate), which is the worst possible option.

In the diagram below, the depiction of this scenario is done. When we are farther away from the delivery we have “Larger Epics”. At that point the precision is very less. And its ok to have lesser precision right now. As we come closer to delivery the precision increases and variation decreases.

Therefore, its more practical to do relative estimations in Agile.

Estimation is a Iterative exercise in Agile

Estimation is not an one-time exercise as it used to be in traditional life. In the traditional way, estimates used to be done in advance and based on the estimates, the delivery used to be tracked.

Agile Estimations are done iteratively. Therefore when relative estimations are done and if there is an error or if they are imprecise, then the estimates self adjust as the Epics get broken down into smaller units.

How do contracts work with relative estimates?

Traditional fixed-scope, fixed-cost contract may not work with relative estimates. Even if they are made to work, there needs to be contingencies to handle these changes.

Generally, the contractual type which works better is the Fixed-time, Fixed-cost, variable-scope contracts. Please click here to read about different type of contracts which may work better with agile.

What Goes into a Story Point Definition

When we define a story point we take various factors into considerations

  • Size (Lines of Code) : Certainly, if there is more to do of something, the estimate of effort should be larger. Consider the case of developing two web pages. The first page has only one field and a label asking to enter a name. The second page has 100 fields to also simply be filled with a bit of text. The second page is no more complex. There are no interactions among the fields and each is nothing more than a bit of text. There’s no additional risk on the second page. The only difference between these two pages is that there is more to do on the second page. The second page should be given more story points. It probably doesn’t get 100 times more points even though there are 100 times as many fields. There are, after all, economies of scale and maybe making the second page is only 2 or 3 or 10 times as much effort as the first page.
  • Risk (uncertainty) : Lets say we want to develop a login functionality with a simple userid and password boxes. Now depending on whether we want to develop this for a travel website or for a bank, the story point definition might differ.
  • Complexity : There might be two screen being developed which has 10 fields each. However, one screen is a data entry screen with a save button to save to database. Another one is also a data entry screen but this is for credit card data and requires validation of the credit card number, the CVV number and the expiration date. Obviously the work that we need to do for the second screen is much more complex than the earlier screen.
  • Skills Available : Certain times we have low skilled people, certain times we have high skilled. We may have to take into consideration the skill levels available with us to make a decision on what is a story point.

Process of Story Point Estimation

  • The team decides the definition of Story Point. This may depend on the above factors or whatever factors the team decide.
  • Typically a Fibonacci Number series is used in a Planning Poker Estimation technique. This sequence is 1,2,3,5,8,13,20,40,100
  • Why Fibonacci – well its related to the broadness of the Epic story as the Epic is bigger when away from point of delivery. When Epic is very big, at that time, the estimates may be 20,40,100 (less precise with more error). When the Epics get smaller the estimates may be 5,8,13,20. When Epics become stories, the numbers may be 1,2,3,5
  • The team members sit together and first decide what is a 2 or 3 or a 5. They don’t really do a bubble sort, but just pick a story which is a 2 or a 3. Single Order of magnitude is not a good idea so generally two stories are taken first one a 2 or 3 and second one a 5 or a 8.
  • The rest of the stories/Epics are compared against the stories selected as reference stories.
  • Calibrations and re-calibrations are common
  • After a couple of sprints, reference of each number is found and then comparison is done against the calibrated reference.

Story Point Estimation is NOT compulsory in Scrum

This is a common misunderstanding among people. Most people feel that Scrum advises Story Point Estimation technique. However, SCRUM DOES NOT RECOMMEND ANY ESTIMATION TECHNIQUE. This is a myth that Scrum makes it compulsory. This is a popular estimation technique since practitioners are able to do the broad estimation quickly using story point estimation technique.

Conclusion

Story Point Estimation is a very effective “Relative Estimation Technique”. This works mainly because of the uncertainty in requirements and we will be able to do only broad estimates when farther away from the delivery point. Story Point Estimation is not compulsory. Scrum does not describe any estimation technique. This is a popular estimation technique used by agile practitioners. However, it is not compulsory.