Product backlog estimation and refinement with Story Points

There's nothing more tedious than estimating development tasks using time as a metric. Product owners who discuss user stories with development teams and stakeholders often find themselves struggling to cope with two completely different mindsets. And need to master the art of compromise.

Technical people hate when they are asked to advise on how long a particular task will take. They are aware of the complexity and uncertainty of their effort, and yet get questions about fixed time scales.

Business people think in goals and benefits, and are aware of the cost opportunity tradeoffs. They need to minimize the effort and maximize the benefits, for that, need a metric that is most often time.

Story points for product roadmap refinement

A sprint planning meeting is looming and our product owner is discussing the user stories with the technical leads and stakeholders. As an agile development team that has mastered Scrum, sprints are two weeks long and include some non-negotiable items.

Our product owner needs to fit as many valuable items in the sprint. He also has to make sure that the sprint is successful and stakeholders aren't disappointed.

Time-based estimation is – for many – the key metric to fit the items in the two weeks sprint.

The shortcoming of time-based estimations is that complexity is reflected in time only, with more days assigned to a specific user story depending on its complexity. Other shortcomings are that the risk of failing to achieve the goals aren't reflected in time measures, as well as the repetition skills of the development team.

Risk, repetition and complexity are three new metrics that Story Points aim at representing replacing time-based estimations.

What are Story Points

Story Points are numbers that identify on a specific scale the level of risk, complexity and experience to put a face value to a user story. The scale – or sequence – can be anything ranging from numbers to paper size or anything else. The only constraint is that the scale used need to represent increasing levels of complexity that double on each step.

A good example is paper sizes. Think of A3 paper being double the area of A4 paper. A5 being half the area of A4 paper and so on. A number-based scale could instead use the Fibonacci sequence starting from number 1, then 2, then 3, then 5, then 8, then 13, etc. The number represents the amount of Story Points that a user story is assigned, representing the effort required, the time required, the complexity and the uncertainty of each user story.

The process doesn't need to be extremely strict and is subject to changes and updates to make it fit with the teams capability, specific product, general vision, etc. Also, if a user story is too small or too large to calculate Story Points, it's fine to leave a small user story with points, or to break down a large story further.

The process

The first step that our product owner will need to properly manage is to set up a scale and explain the new process to stakeholders and development teams, with the ultimate benefit of making better estimates and better collaboration.

In principle, it's all about collaboration. The more the team understands the new estimation process, the more the estimation will end up being precise.

One good planning strategy is to keep discussing user stories with team members and introduce estimations based on Story Points gradually. Asking team members to come up with an estimate and number representation will help the product owner to know team members better, what to expect, and make more accurate predictions in preparation for the sprint planning meetings.

An important point in the process is that the product owner keeps his prerogative of making the final decision on Story Points estimations and what user stories to be included in the sprint.

The process ends with a Story Point metric assigned to each user story, and sprints planned to include a certain amount of stories based on the estimated total of Story Points that can be handled in two weeks.

Repetition and iterations will make the estimation more accurate with time. A proper understanding of how many Story Points can be handled in a sprint can only be achieved after several sprints, using a revised sequence or scale, or balancing the weight of risk, complexity, time and uncertainty assigned to each scale item.

Making the process more human

I'm certainly fond of measures and reason. I'm also experienced in dealing with all sorts of human natures and mindsets – and balancing the business and technical requirements and benefits.

I believe that processes helping people manage business efforts should be helped become successful and fit in the team culture with some basic psychology.

High-risk and high-reward stories are great for morale as completing those have an impact. Yet, the high-risk and complexity can draw the team down if things don't go as expected.

To make the process of planning sprints and deliverables more rewarding and decrease the risk of demotivation, I link to introduce a balance when picking the user stories to give the team some easy wins to show or think off.

Balancing high-reward stories with easy wins, stakeholders see a number of items thicked off the road map, development teams see commits going through code review and to production have an impact on the end user.

I like to keep sprints in balance with 1 large 8 points story, one smaller yet meaningful story of 5 as a backup plan for morale, and low-value stories to fill my sprint capacity.