Friday, February 25, 2011

Agile Value Capture Metric - Are you spending your time Building Value?

When applying an Agile mindset, a team should consider the value of each task that they are working on.  Agile often brings value concepts into play and determining the value of tasks is one way to achieve this.  Is the task considered value-added or non-value-added.   Sometimes folks have a hard time wanting to separate tasks into value and non-value because it highlights the non-valued tasks folks are doing. However, if you really want to know, then you must do this (typically at the Product team level).  Sometimes the answer surprises people.   
Keep in mind that in Agile, value-added tasks refer to only those tasks that are directly related to building the product and that your customer values.  This would primarily include user stories and the attributes of this work related to the “done” criteria (e.g., incrementally designed, developed, built, tested, etc.) in order to complete the user story.  Remember, value is from the customer's perspective.  

On the other hand, non value-added tasks do not contribute directly to building the product.  There are tasks that are out-right of no value including administrative related tasks, writing status reports, all-hands and other status meetings.  There are tasks with no direct customer value but have benefit to quality including spending time on correcting defects, tasks related to technical debt, performing refactoring. Please understand, there are levels of internal value in doing these things and the goal is to make the value levels of the work transparent. 

A good practice in Agile (e.g., value capture metric) is to capture all related work or activity a team does in a sprint (as backlog items) to understand what are value-added tasks vs the other tasks that we do.  For each story or backlog item, assign it an attribute of either “value-added” or “non-value-added”.  You can track this on a sprint basis (or release basis) or trend it over time (from sprint to sprint).  This is a team-based metric so it is for the team's eyes only.  Below are some examples:
Chart 1: Value of work per Sprint (can be rolled up to the release level)

Chart 2: Value of work per Sprint (at the detailed level)

Chart 3: Value of work from Sprint to Sprint (Trend line)
The big advantage of this type of metric is that it helps you 1) be aware of the value and non value related work that your team is doing and then 2) it allows you to make adjustments if you want to get to a more value-added stream of work.  Also, an important caveat: this metric is a team-based metric and not meant to be shown to management.  It is for the team to see where their work is being spent.   

Whether you call it value and non-value work, the key is that much like the prioritization of the backlog, that you become aware of the priority of the various types of work that is occurring on your team. This metric also brings transparency to the types of 'work' where the team members are spending their time.  While this may force you to make some tough decisions (what is value-added and what is not), it will be worth it in the long run to get your team more productive and focused on the value-added work for your customers.  This can help you on your Agile journey! 


  1. If your team works on user stories collected from many customers, you will probably have difficulty convincing individual customers of the value of refactoring.

    If your team works on a project for a single customer, that customer should see the value of refactoring when you tell them that the team's velocity with go down if they aren't refactoring and reducing technical debt consistently. If they don't believe it, just track velocity and show how it goes down over time.

    Of course, you want to allocate your energy toward reducing technical debt strategically. If you refactor and reduce technical debt in areas that the team rarely has to touch or which is already slated to be removed or replaced, you provide little value to either the customer or your own organization. High return on investment (ROI) areas for refactoring are those the team currently works. As you fix bugs, refactoring reduces the fragility of code in the areas that are demonstrably buggy. (After all, you're there fixing bugs, so that code is buggy.) As you build new features, you refactor to keep technical debt down so that it doesn't reduce velocity in adding future features.

  2. While this is an innovative approach, it does not seem to be new. Moreover it introduces an additional and considerable effort in setting the values atop doing the work... additional effort which, by its nature and distraction, would seem to add little value to the Customer. Especially as traditional project management has a tool for this value metric. It's called earned value, and it does exactly the same thing as this metric, when the 'value' is simply cost of the sprint. Then in a properly constructed work breakdown structure, this metric is calculated automatically.