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 into Themes, Epics, 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.

Why?

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.

Browse more templates


Subscribe to the to be notified when I upload new Articles, Videos, Templates and Tips!

Product Backlog Template with Priority Overview.xls

Related Articles:
Share this!
  • Print
  • PDF
  • del.icio.us
  • Digg
  • DZone
  • Reddit
  • Technorati
  • StumbleUpon

6 Responses to “Value Points – Estimating the relative value of a User Story”

  1. Sam says:
    August 12, 2009 at 9:23 pm

    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?

    Thanks.
    Sam

  2. taraleewhitaker says:
    August 13, 2009 at 8:23 am

    Hi Sam,

    Great questions!

    I’m actually in the process of writing a post about the Agile Estimation Workflow. Go ahead and subscribe to my RSS feed to be notified when I post it. I’m hoping to do it this week and I’ll be sure to answer your questions – Keep them coming! :)

    Thanks,
    Tara

  3. taraleewhitaker says:
    August 22, 2009 at 9:40 am

    Hi All,

    I’ve just finished writing about Agile Estimation and the Cone of Uncertainty – this answers most of the questions above.

    Tara

  4. Raj says:
    December 9, 2009 at 10:47 am

    Hi Tara,
    There is one question which bother me a lot and that is in Agile Scrum we have fix time for sprint e.g. say 20 working days;we have to complete the work or estimated user stroy points in this time frame. How this can be achive without knowing how much user points can be completed in the specified days? This in turn link days with user stroy point!!!

    Please suggest me on this.

    Thanks

  5. taraleewhitaker says:
    December 9, 2009 at 12:48 pm

    Hi Raj,

    The number of story points that a team can complete (on average) in one sprint is known as their ‘velocity’.

    Before you start estimating stories, make sure that everyone agrees on what a 1 point, 3, point, 5 point (etc) story ‘looks’ like. Some teams will bring these examples along to their planning poker workshops as a reminder until they get used to their scale.

    So, for example, all 3 point user stories should on average take the same amount of effort to deliver. With that in mind, assuming each sprint has the same amount of effort available (same number of people in the office, with the same skillset (ideally the same people!), for the same number of days) then the same number of points will generally be delivered in the pre-agreed number of days.

    It usually takes a few sprints before a team can get a sense of their true velocity. This velocity then acts as a starting point for negotiation – more or fewer points may actually be committed to depending on other influencing factors (e.g. team members on holiday etc.)

    Make sense?

    Tara

  6. Software para Gestión Ágil | Lycka Bonita says:
    February 28, 2011 at 8:12 am

    [...] en puntos de la historia para estimar el tiempo necesario para completarse con éxito, y también puntos de valor para estimar el valor que aportará su implementación y [...]