Get more from software sprints: assess business value for better prioritisation

How do you prioritise the right software development activities at the right time? In this blog post, we look at how you can set out to get the most value (in terms of progress and cost) from sprints in software development.

Typical prioritisation

Usually, in Agile or Lean-Agile led software development, development happens in a series of sprints. (At Bluefruit Software, our sprints last two weeks.)

During sprints, software engineers and testers work on user stories (a work item that is part of a user’s experience of software or a product overall and not a feature in of itself). These user stories are decided on and prioritised right at the start of the sprint, sometimes in meetings like Three Amigos.

The prioritisation of these user stories (which sprint they’ll be worked on and in what order) is often a combination of prioritising techniques, frequently points based. The software team might use something like effort estimation (with a method like Planning Poker) to allocate a points value to an individual user story. This is mixed with what the product owner (along with stakeholders) say are priorities, using methods like must have, should have, could have and won’t have (MoSCoW).

It’s best to work on these estimates together: software teams, product owners and stakeholders in the same room (or on the same conference call). Doing this helps everyone gain a shared understanding (an important element to planning) of why things take as much effort as they do. It also helps software teams better understand what the needs and priorities are of the product owner and stakeholders.

Points estimation basics

Software teams calculate effort points by identifying the user story that involves the least amount of effort (is the easiest thing to be worked on) and giving that one point. Then all other stories are multiples (up) based on that user story. Where team members disagree on effort, a discussion can happen, enabling consensus.

In MoSCoW style assessments, it starts the other way—you identify the highest value “must have” user story and assign that a high point value, say 1000. From there, you agree on the value of each user story as a fraction of that initial 1000.

Balancing these two against each other, you and the software team can agree on what you’d like to see delivered in the course of a sprint.

Estimating this way can be an excellent approach to agree on priorities for a software team. In many cases, methods like this align story priorities with stakeholder expectations and ensures the output from a sprint is what is needed, shifting the focus from being just pure cost.

But what if estimating like this just isn’t delivering what you expected?

Understanding a more realistic business value of each user story is a great way to discover what the real priorities should be for software development.

Doing this takes you beyond just assigning a cost to user stories.

Cost alone isn’t enough. The software team needs to know the business value

If the amount of effort involved in delivering each user story is approximately the same, it’s safe to say that the cost of delivering each user story will be the same as well. But it’s unlikely that the business value of each user story is the same.

For instance, say you were developing embedded software for an electric bike.

Getting specific user stories completed is essential, but an electric bike (in many markets) needs to meet individual regulatory requirements. That directly affects the ability of the finished product to be sold—and so the user story about meeting regulations is of far higher value than a user story about logging software events. But perhaps not of much higher value than the user story around being able to turn the bike off and on (a key feature in an electric bike).

Finding out the business value behind user stories:

• Helps teams to prioritise user stories where it’s less clear what needs to happen and when.
• Helps you know when development needs to be paused and re-assessed.
• Enables discussion between the software delivery team, product owner and stakeholder.

So how do you estimate the business and monetary value of user stories?

A simple method for estimating the business value for user stories

Try out the following:

Step one: business value (points)

Assign business value points to user stories, base the points on what you believe will deliver the most business value. Assign the highest value (say 1000) to the user story that will deliver the best value then base the other user stories as fractions of that amount.

You can stop at just doing this, but if prioritising is still proving to be difficult, you need to do step two.

Step two: business value (monetary)

Estimate the monetary value for the whole project (this should be much higher than the cost of the project) then divide this by the total business value points. This gives you a monetary value for each business value point and therefore a monetary value for each story. You now know which user stories cost more than their value. With these figures, you can track delivery of business value across sprints and plan (still with the help of effort points), which user stories to prioritise.

In our earlier electric bike example, the business monetary value of user stories could look something like this:

Start with user stories that deliver high business value and work down (within reason)

The total business value of early sprints would usually start high with the value slowly decreasing as user stories are worked through by the software team.

If a user story needs to happen for anything from the project to be entirely possible—that should still go first. But everything else can then follow as estimated.

There may come a time when the value of delivering the user stories is less than the cost of performing a sprint. Prioritising in this way enables you to see that at the project level. When it happens, it acts as a trigger for discussion, where you and the software team can discuss if the user stories involved are worth delivering or not, or if new ones need to be considered.

Sense check the business value against UX research, using prototyping and MVPs

If you’re also carrying out sustained UX research to enable User-Centred Design, along with prototyping, MVPs and MMPs, you then have further information to fine-tune priorities when it comes to user stories. It means, when specific user stories are done, you can check whether the backlog for development reflects what users need and the real business value you’re seeking with your product.

Check out our further reading suggestions below for more information on how to work with Lean-Agile teams and best practices for embedded software development.