What are story points?

Story points are a common means of estimating work while using agile frameworks such as Scrum and eXtreme Programming.

Challenges related to estimating

When engineers estimate the time to complete any task, they often estimate an ideal engineering day. Unfortunately, ideal engineering days don’t exist. When you factor in time spent on other activities such as Slack, email, meetings, and other administrative and non-technical tasks if they are lucky, they will get 50% of productive time.

Sometimes work is easy to estimate. Items that have an air of repetition, such as reading some data from a database and displaying it on the screen, are simple to understand and estimate. Repetitive or similar work is also easy to estimate. However, software development often requires bespoke solutions that have never been attempted before (at least not by the team doing the estimates). They may also need to integrate with components developed by other groups. As the complexity increases, so does the uncertainty.

When asked to estimate something bespoke or complex, we are often overconfident in the time it will take to complete the task. A significant contributor to this is the fact that we can’t predict every single step that might be required. Tasks often emerge as the work is underway, as unforeseen challenges generate additional steps. This overconfidence results in underestimating the time and effort to do the job.

Benefits of estimating

Not everyone likes estimating, and it takes time and effort to do. Given the costs and challenges of doing it right, why bother at all?
Benefits for development teams:

1. They know how much to plan in a sprint so they can work at a sustainable pace.

2. They’re more likely to create a done increment by not over-planning the sprint.

3. Increases the understanding of requirements and implementation strategy through discussion and elaboration

Benefits for product owners:

1. They’re to forecast longer-term delivery of their product.

2. They can assess the “value for money” or “return on investment” of items

3. They get visibility of technical risks associated with large items

Critical concepts in story pointing

Story pointing brings together several concepts

Relative estimation is easier than absolute estimation. It’s much easier to compare two product backlog items and say one is twice as hard as the other. It’s much harder to think how many lines of code one thing takes and therefore how long it takes to code and test.

Utilising the diversity of the whole team creates better estimates. Also known as the wisdom of crowds. Teams bring a diversity of thought and opinion. Different team members will see the same problem from different points of view, allowing a broader input into the discussion of the problem. A simple bug fix may only take one line of code to change but many hours of regression testing. If only one opinion is considered, the size of the item may be way off.

Accuracy and understanding reduce as items become larger. The size of diamonds is measured in mm usually to 1 decimal place. The difference in that extra 0.1mm can be quite significant and worth discussing. Comparing that to Jupiter, which has a mean radius of 69911km, it would be ridiculous to argue about an extra 0.1mm. Story points use a nonlinear scale such as the Fibonacci sequence, which increases the gaps between the numbers as it increases. There is a 34 but not a 33 or 35.

Story points are not about the time it will take any individual to do the work. In Scrum and XP, one person isn’t assigned work at the point of estimating. The whole team remains the owner of the work, meaning anyone on the team may pick it up. Instead of individual time efforts, story points represent a combination of size, complexity, and risk. How much work can be completed in the sprint is calculated using the team’s velocity (how many points did it complete in the previous sprint).

Approach

1. Calibration

Before you get started estimating points, the whole team needs to calibrate what a point is worth. To calibrate your scale, choose an item from the backlog that is simple, and everyone in the team understands and defines on the scale. (e.g. 2 points). To further improve your calibration, find an example further up the scale maybe four times bigger, and define that as an 8. Calibration of the estimating scale will significantly improve your success with estimating.

2. Agree on how to manage differences

The development team needs to agree on how they will manage differences in estimates. How many rounds will they go and what should they do if the estimates don’t converge? To get the benefits of group estimation, a minimum of two rounds will provide dialogue to tease out assumptions. The facilitator may need to remind the team that there is limited value in long debates between similar estimates – if the team is struggling to agree if it’s a 2 or a 3, just pick one and move on.

3. Estimation Meeting

The estimation meeting proceeds as follows:

1. The Scrum Master, who will not play, chairs the meeting.

2. The Product Owner provides a short overview of one product backlog item (PBI) to be estimated. The development team asks questions and discusses to clarify assumptions and risks. A summary of the discussion is recorded by the development team.

3. Each member of the development team compares the size of the PBI relative to the calibration PBIs and chooses their size estimate. During the discussion, numbers must not be mentioned at all about feature size to avoid anchoring.

4. Everyone calls their estimates simultaneously. Only the development team may estimate. The product owner is permitted to enquire as to why something is a certain size and may enter a negotiation on the scope which may affect the size of an item.

5. People with high estimates and low estimates offer their rationale for their estimates, and then the discussion continues. During the debate, assumptions should be aired, and the Product Owner can provide clarity.

6. This step often surfaces a different understanding of the scope or implementation, which can then be clarified and agreed upon. The person who gave a 2 may know an easy solution, but the person who gave a 13 may anticipate a difficulty no one else thought of.

7. Repeat the estimation process until a consensus is reached. Or sufficient convergence is achieved as per the development teams’ own rules.

It’s not about the points

Success at the end of a sprint/iteration isn’t measured by the number of points completed or the ratio of planned vs actual points achieved. Success is measured by how much value was created. Points are a means to help create value, not an end in themselves.