Value Points – Estimating the relative value of a User Story

priorityValue Points can be used to measure the relative value of User Stories using a Fibonnaci Sequence. Although not appropriate or particularly necessary in all cases, Value Points can help you to prioritise a product backlog and convey the relative importance of User Stories to a Software Development Team. This approach becomes increasingly useful as teams scale to cover multiple projects combined with Business As Usual activities.

If you are a Product Owner or a Programme Manager, you will be all to familiar with Return on Investment (“ROI”) models, Net Present Value(“NPV”) and Internal Rate of Return(“IRR“).

In short:

  • ROI measures how much money you will make off the back of an investment.
  • NPV measures the desirability of an investment compared to the minimum expected return over a pre-defined number of years.
  • Internal Rate of Return measures the percentage return of an investment after tax.

The traditional ROI model approach is useful when applied at a project level, particularly when attempting to measure viability and/or secure funding, however it is time consuming, requires business analysis skills and is wrapped up in a whole host of assumptions.

In Agile Software Development, we break projects down to Themes, User Stories and Tasks. We then define a minimum feature set (Minimum Marketable Feature(s)) and attempt to schedule development in a way that maximises ROI early on.

So, what happens when you need to measure the value of a User Story?  Do you produce an ROI model? What if there’s no direct financial return associated with the story?  The reality is that this would be an unrealistic expectation due to 1) the time/effort involved and 2) the level of  granularity that would be required.

So, what to do?

I started using Value Points in hopes to simplify the process of measuring relative value. This scale uses the standard Fibonnaci Sequence: 1,2,3,5,8,13,21,34,55,89 as a metric.

In the same way that Story Points can not be converted to Hours, Value Points can not be converted to Financial Return.


Because when we measure value, particularly across Business As Usual, there are so many reasons for doing something – not all of them will offer an immediate financial return:

  • Strategic – if we don’t make this investment, we will no longer be able to maintain our market share
  • Compliance – if we don’t make this investment, we could be in breach of the law(s)
  • Revenue Generation– if we don’t make this investement, we’ll miss out on a chance of making X money
  • Risk Management – if we don’t make this investment X could happen to us e.g. stakeholder dissatisfaction etc.
  • Cost Avoidance– if we dont make this investment, we could realise additional costs in the future
  • etc…

Value Points can offer a useful tool to help with the prioritisation process e.g. you can plot effort against value to maximise delivery of those stories delivering the highest amount of value for each unit of effort.

Value Points can also empower the development team to identify the most appropriate solution for a particular card – e.g. the value’s low, so I’ll not spend as much time on it as one of the higher value cards.

I’ve created a Product Backlog Template that provides some insight into the health of your product backlog – the idea is to pack it with as many low-effort/high-value stories as possible.

This template uses a simple formula to help you prioritise your stories:

Value Points – Story Points = Priority Points

It also allows you to do the following:

  • Assign stories to sprints (release plan)
  • Calculate the number of releases required to deliver your backlog based on your velocity
  • Calculates how many sprints you can afford to deliver based on your project budget
  • Plots your user stories on a chart based on Effort vs. Value

Feel free to download the template below – let me know your thoughts.

Product Backlog Template with Priority Overview.xls
Product Backlog Template with Priority Overview.xls
Related Articles:
Reblog this post [with Zemanta]


  1. Hi Tara,
    I’m fairly new to Agile, saw your blog with lots of very interesting articles and thought you might be able to help me. I’m struggling a little bit with one aspect of Scrum: the initial estimates. Here are my questions..

    1- Who makes those initial estimates? Product owner + team together?

    2- In which unit do they make those initial estimates (points, hours ..)? The reason why I’m asking is because I understand that user stories are counted in points whereas tasks that derive from user stories are counted in hours or days.

    3- When exactly to they produce those estimates? Before the 1st sprint?
    If this is the case, based on your experience, how does the team + product owner react when they have to re-estimate again the top priority items of the first sprint considering that they might have done this for the full product backlog the previous day before? Don’t they feel like it’s a waste of time to spend so much time on estimation?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s