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 in 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 to doing it right, why bother at all?
Benefits for development teams:
- They know how much to plan in a sprint so they can work at a sustainable pace.
- They’re more likely to create a done increment by not over planning the sprint.
- Increases the understanding of requirements and implementation strategy through discussion and elaboration
Benefits for product owners:
- They’re to forecast longer-term delivery of their product.
- They can assess the “value for money” or “return on investment” of items
- 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 a different point of view, allowing a broader input into discussion the problem. A simple bug fix may only take the 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 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 remain owners of the work, meaning anyone in 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).
Before you get started estimating in 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 define that 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 need 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 are 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:
- The Scrum Master, who will not play, chairs the meeting.
- The Product Owner provides a short overview of one product backlog item (PBI) to be estimated. The development team asks questions and discuss to clarify assumptions and risks. A summary of the discussion is recorded by the development team.
- 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 in relation to feature size to avoid anchoring.
- 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.
- People with high estimates and low estimates offer their rationale for their estimate, and then discussion continues. During the debate, assumptions should be aired, and the Product Owner can provide clarity.
- This step often surfaces a different understanding of the scope or implementation, which can then be clarified and agreed. The person that gave a 2 may know an easy solution, but the person that gave a 13 may anticipate a difficultly no one else thought of.
- 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.