To start with, I want to make a kind of very simple yet radical conjecture; I strongly believe a couple things;

  • That Productivity is The Goal, and
  • That productivity is delivering the most amount of value for the least amount of work.

So mathematically;

P = V / W

I think this way because experience tells me when we consistently reach high levels or productivity;

  1. We are profitable
  2. We have a sense of purpose
  3. We have what we need to do the job
  4. We are learning
  5. We can do it indefinitely
  6. We are empowered to solve problems and improve

(Side note: I am one of those people who believe that happiness is a trailing metric. Being able to do good work causes happiness; or not. I have seen many teams start very happy. But this is another article)

In my last 2 blog articles I try to demonstrate why limiting work in progress results in faster throughput, or flow. Understanding product development process flow is essential to efficiency or getting stuff done expending the least energy or getting the most for the energy you spend. Now I want to hop over to the other side and discuss value. Value is about effectiveness. Many organizations also think of this as impact.

In the course of my coaching, I have consistently seen that the overwhelming majority of scrum teams do not consistently track value. Many teams are told why a story is valuable or that they all are or that someone high up said so. But there is not a consistent visible indicator of value. This puts the team at a huge disadvantage because without it, productivity is not visible. When value is unknown, people jump to other numbers like velocity and others that are not a measure of productivity, often with pretty disastrous outcomes.

I think there are several problems trying to quantify and estimate value. The first biggie is the second word I used; recognition that its an estimate or guess or hope or hypothesis or dream. That word is a dog whistle to all agilists. We know from estimating other things (like story size) that no one can estimate exactly so we estimate relatively. We know that estimation accuracy gets better the closer in time to reality so we estimate and re-estimate. We know that estimation accuracy goes down as size goes up so for relative estimation we use a scale where bigger things result in a wider range.

So what does all that mean? Are you saying give up the 5 tab ROI Excel? Well as some point you may need this no matter how unbelievable it is. But on a daily basis it doesn’t help us know what to do. Another problem with that sheet is that it drives you to do the whole big thing at once rather in small pieces that keep through-put high. For many of the same reasons scrum moved to relative sizing rather than exact hours it is a good idea for the business (in the body of the Product Owner (PO)) to move to relative value points and away from dollars. In reality, we don’t know how many hours something will take and how many dollars it will make so let’s just get over that and try something else.

So how have I seen this work? An example organization used a modified Fibonacci scale for value points. They used 3, 8, 13, 21, and 34. They didn’t use the bottom numbers because no one asked for things that had no value and on the other end the guess was bigger (a 13 is just bigger than 8 and less than 21). The team or PO (or PO group with Product Managers) would agree to a keystone story (or epic) and set that to 8 for calibration. Then they could very quickly go through the whole backlog of ideas and sort out more or less valuable. They could then add up to get a total backlog value point number. (CAUTION: You cannot compare the value of one backlog to another based on points). As the scrum team splits stories to get them to a size to maximize through-put, the PO will re-estimate the value of the split pieces.

Your organization can do something different. The idea is to make it as easy as possible to make value as visible as possible. Here are some benefits;

  1. Teams get visibility into relative productivity
  2. Improved priority setting is possible
  3. Aligned decision making is empowered lower in the organization
  4. Disconnects size of work from value; many projects become very unproductive by equating these.
  5. Splitting stories is less scary for a PO
    1. This increases flow
    2. This decreases the impact of or can eliminate dependencies
  6. Allows value burn-down;
    1. This can focus the team on building the most value parts first rather than getting it all done
    2. This may radically reduce the duration release plan as you discovery what’s valuable enough to release.

What do you think?

In my next article I will discuss how to use Size and Value to set priorities in a way to maximize productivity.

Leave a comment