A key principle of Agile is responding to change over following a plan. But that can leave us at the mercy of constantly changing opinions and at risk of losing sight of what matters for our business. How can we make Agile planning and prioritisation transparent, fast and always in line with our business objectives?

Prioritisation is important at many levels. At a strategy level, executives must decide on business direction and the business strategy and changes to support that. At a portfolio level, managers must decide which projects to prioritise. And within an agile project or programme, a product owner is responsible for grooming and prioritising the backlog and setting Scrum sprint goals.

Within high-uncertainty situations such as new product development or startups, the stakes are even higher. Even using techniques such as Lean Startup, we still need effective ways to prioritise experiments and decide when to pivot.

What techniques can help us prioritise effectively, whatever level of the organisation we operate at?

Agile planning and prioritisation based on value / cost

The key to agile prioritisation is to make the decision criteria explicit – and they should include the factors that, if improved, are valuable to the business. I’ve explained how to do that in my article on uncovering agile business value.

For example, I coached a large business transformation programme that was automating manual processes for publishing data in around 10 business areas. Despite involving so many businesses, over a hundred people and all sorts of complex technology, fundamentally the programme could be summarised by three factors that the business stakeholders considered valuable:

Factor Current Goal
Time at which data is published 12:00pm 8:00am
Effort to produce the data per day 1000 person/hours 100 person/hours
Accuracy of data (errors post-publication) 10 1

With the factors and goals so clear, we can apply a fundamental idea of Agile and ask the question “What small step can we take that adds the most value for the least cost?”

To decide that, we can draw up a grid so we can assess all the ideas that we have for generating value. I’ll talk about “ideas”, but you can put business strategies, improvements, user stories or designs into the columns – basically anything that is an idea or a solution for producing value for the business.

We’ll assess the ideas against these value factors. For example, we might be arguing over whether to transform business A first or business B, or perhaps a small process simplification in both areas would be better:

Transform Business A Transform Business B Process simplification

This is a good start, but an idea might not be good if it generates value but is very costly. So, we need to include the cost in our assessment.

We might assess ideas against the financial cost, particularly at a strategic level. But often it’s useful to assess the cost of an idea against the finite resources that we have available. At a project level, assessing cost against developer time (or story points) works well if you use this technique for backlog prioritisation.

In our example, we’ll assess cost using two resources: the amount of business analysis time and developer time available.

Transform Business A Transform Business B Process simplification
Developer days
BA days

Now we populate the table with the effects that we estimate each idea will have on the value or resources. When you use this technique, it is perfectly acceptable to make an informed guess. The trick is to estimate fast and then, if you choose, you can refine the table by spending time on better estimates for the highest-priority items or running experiments to validate the guesses.

Transform Business A Transform Business B Process simplification
Time  -1hr  -0.5hr  -0.1hr
Effort  -90hr  -50hr  -5hr
Accuracy  -2  -0.5  0
Developer days  80  30  0
BA days  20  20  5

In this example, notice that our idea of “process simplification” is something that the business analysts can do on their own – it doesn’t need a new system or any software to be written, so there’s no developer time but it still adds value to the business. An important aspect of these value-based techniques is that you can consider any idea that adds value to the business – not just building software.

So now, we’ve assessed all the ideas, but how can we tell which are best – in the sense of most value for least cost? The factors use different units, so how can we combine them?

The trick is to convert the estimates to the percentage effect on the goal (or the % of available resource used) because this normalises all the factors. If you’ve got the numbers in Excel, it’s trivial to create a second table that calculates these percentages.

For example, reducing Time is valuable and we ideally want to go from 12:00pm to 8:00am – a 4 hour improvement. The strategy of “Transform Business A” makes a 1 hour improvement, so that’s 25% of the way towards our goal.

If we then add the percentages of the value factors and divide by the sum of the cost percentages, we  have a value/cost ratio for all the ideas. For example, the contributions of “Transform Business A” to the three business value factors are: 25% + 10% + 22% = 57%. The use of the two resources (assuming we have 300 days available) is 27% + 7% = 33%. And so the ratio of business value to cost is 57% / 33% = 1.72.

Transform Business A Transform Business B Process simplification
Time 25% 13% 3%
Effort 10% 6% 1%
Accuracy 22% 6% 0%
Developer days 27% 10% 0%
BA days 7% 7% 2%
Sum of value 57% 24% 3%
Sum of costs 33% 17% 2%
Value/cost 1.72 1.42 1.83

So, based on these estimates and taking the highest benefit/cost first, we should prioritise the process simplification first, business A second and business B last.

This grid is called an impact estimation table.

Seems like process & tools. Where are the people and interactions?

An impact estimation table is a rational decision-making technique. So, it’s important not to let it override intuition and gut feel. If something feels wrong about the prioritisation then investigate that feeling: the factors might be wrong, the targets might be wrong or there may be some other complicating factor that the grid can’t take into account.

As with many Agile techniques, this is primarily a tool for provoking a good conversation. It makes people in the discussion aware of the factors that are important to the business, it uncovers and challenges assumptions and it keeps everyone honest in making sure their ideas contribute to those factors. Then they can focus on interesting debate about improving these ideas and creating better new ideas.

Responding to change

Impact estimation tables are extremely useful for re-prioritising and re-planning as changes happen in a business or a project. Typically there are three kinds of changes:

  1. A new idea for creating value. When a stakeholder or someone in the team suggests a new idea, it’s straightforward to rate it against the value and cost factors and find its ranking amongst other ideas by value/cost. With minimal effort, ideas rise or sink in ranking and the justification for their ranking is transparent to everyone.
    By allowing ideas to enter your backlog easily, you can encourage wider engagement and contribution in your decision making. And by estimating the value/cost in partnership with the person suggesting the idea, you can encourage creativity and thinking of ideas that are more value-adding and cheaper.
  2. New learning about the ideas. Once you have constructed an impact estimation table, typically you’d start work on the most valuable idea. In Agile fashion you could break it down into smaller valuable steps, testing assumptions and risks early. If an early small step reveals a false assumption, it’s easy to feed that back into the table and check whether the overall idea is still worth pursuing, or you should change tack to a new idea. Impact estimation provides a fast and methodical way to decide when to pivot for people applying Lean Startup.
  3. The market/business changes. Occasionally, something changes at a high level. The market shifts or there is a new learning at a strategic level and the business decides to shift direction. The project may still be valid but needs a change in direction.
    Impact estimation tables allow you to change the goals (for example, we now need data at 7:00am not 8:00am) and, if you’re using a tool such as Excel, every impact and value/cost can recalculate automatically. Strategic changes might cause you to add or remove value factors but, even then, the re-prioritisation is much faster because you only need to estimate the new factors and all your other work remains valid.

Is this fast and transparent?

So how does this technique rate in our desire to make Agile prioritisation fast, transparent and always in line with business drivers?

This is a highly transparent technique – you can see every idea and the contribution it makes to delivering value for the business. The value/benefit ratio gives you a rational justification for why some ideas are chosen over others.

Many change management processes take place behind closed doors and seemed designed to stop any new ideas. In contrast, this level of transparency allows you to be inclusive of new ideas and challenge anyone to be creative: “we welcome any new idea, it will compete with others in this table for which delivers most value – can you think of an idea that’s even more valuable than these?”

The speed is a matter of facilitation. Other techniques look like they are simpler and faster but often get slowed down by lots of unproductive debate because the decision-making criteria are hidden. Conversations around impact estimation tables can be heated but are typically much more focussed on discussing what’s important to the business and creative ways of getting that value.

The real benefits of speed come when there’s a need to re-prioritise: new ideas and learning can be incorporated rapidly and even strategic shifts in direction can be accommodated efficiently.

What are the downsides?

This is my go-to decision making technique, although I tend to customise it to situation. There are simpler versions for getting started or for one-off decision making and there are more sophisticated versions for strategic work and handling high levels of uncertainty.

I tend to find a few obstacles to using the technique and situations where it isn’t appropriate:

  • A perception that it takes longer
    • If you trust a single person with a clear vision who makes effective decisions, then impact estimation takes longer.
    • It can take a long time if you don’t facilitate the conversations well – encourage people to make guesses and keep up a high pace of new ideas and estimating. You can improve the guesses after the discussion, if necessary.
  • People don’t like numbers
    • People may have had bad experiences of “targets” and the consequences of not reaching them.
    • People feel they’re going to be held accountable to the numbers (which is a bigger fear if they are guessing the numbers)
    • Some people just don’t like numbers
  • People don’t like transparency
    • Transparency can threaten people’s authority – their power may be taken away (into the grid)
    • Transparency can threaten people’s standing amongst their peers – what if their ideas are always “bad”?
  • It looks scary if you weren’t involved in creating it
    • Be very careful about showing people the end product table – it can be so different to their existing way of making decisions that it appears alien and difficult to understand. Typically, if they were involved in creating it, that’s not the case.
  • It makes people think very hard
    • Uncovering the value makes people think hard. Estimating the value in a methodical way makes people think hard. That can lead to exciting, motivating, creative conversations for some people, but it can also be hard work and challenge assumptions that people would rather not have challenged.
  • It’s a very rational process
    • It’s not obvious how to include feeling and intuition into the process (FYI: it is possible!)

Interestingly, as a coach, the kind of objections you get tell you a lot about people and the organisation and sometimes point to deep issues affecting the organisation’s performance. Sometimes, you can adapt the technique, sometimes you can use a different technique that suits where people are now and sometimes you address the underlying issue.


I hope I’ve given you enough information to try this yourself – please let me know how you get on and feel free to ask questions in the comments below or by email.

I frequently teach this technique to people (usually by helping them prioritise their strategic ideas or projects), so please get in contact if you’d like some in-depth help using it.

What Next?


Impact Estimation Tables were developed by Tom Gilb. For more in-depth information see his book “Competitive Engineering”

Pin It on Pinterest

Share This