How to measure your speed with your business value ? (Lean Software Development Part 3)
There is a french idiom that basicaly is
No use to run, all that is needed is to start on time …
an agile engineer would add
… and to go in the good direction
Indeed, velocity or mean cycle time as speed measures have their shortcomings :
- Can be falsified by story point inflation !
- Does not tell the team or its product owner whether they are working on the right thing.
Wouldn’t it be great if we could track the business value we are creating instead ? Wouldn’t it be more motivating for developpers to know how they are contributing to the bottom line ? Wouldn’t it help various people to align inside the organization ?
How to track and prioritize based on your business value
From Reinertsen’s Flow book, we learned that the cost of delay is the main driver of the value creation : the faster you deliver a feature, less you spend the cost of delay of that feature, the more value you are creating for your company. This article suggests that the cost of delay can be computed with the following formula :
cost of delay = f(user business value) + g(time criticality) + h(risk reduction opportunity)
This other article suggests that they are different types of tasks that corresponds to the different terms of the formula above.
Here is how we could link the 2 articles :
- Stories with deadlines : either through legal or market constraints, not doing this will put you out of business (‘time criticality’ in the formula)
- Stories that influence the bottom line : by increasing the sales figures when delivered, or decreasing them when not delivered, which is kind of the same (‘user business value’ in the formula)
- Risk reduction tasks : by mitigating risk or streamlining the process, these tasks actually improve the bottom line of other stories (‘risk reduction opportunity’ in the formula)
The later type of task will be detailed in other articles. Let’s focus on the two others.
The case of the deadlined feature ?
First, I’d say its business value is 0, until it’s too late. You should not be working on it too soon, but you should not be working on it too late neither !
In his book The Art of Agile Development James Shore details in great details how an agile team can commit to deliverables (I really recommend this part, I might even write a post about it). He explains that in order to commit, teams should multiply their estimates by 4, or by 1.8 if they are very rigourous in their application of all the XP practices.
So a rule to handle such a task could be to
- estimate it
- multiply that estimate by 4
- substract this time from the deadline
- prioritize it so that it can be started at that date, but not earlier
- don’t expect to be creating any value by completing these stories
What’s the business value of other typical user stories
This article suggests that in this case the cost of delay is equal to the business value of the feature for the user. But how can we have an idea of its actual user business value ?
Before actually selling and getting the money, it’s just an estimation. With the good information, some people will make better estimates than others, never the less, it’s still an estimate. Let’s try a “Business Value Poker” ! Here are a few ideas about how to conduct this:
- Estimate business value at the same time as you estimate the complexity of a story
- Create some business value $ poker estimate cards, write an app for this, or bring in some Poker Chips to estimate the value
- Invite some business people (sales, marketting …) to the meeting to get real knowledge (being organized as a feature team will help)
At the end, when you have the estimated cost of delay and duration of every task, you can directly prioritize using the WSJF (Weighted Shortest Job First) :
WSJF = Cost of Delay / Duration
Just do the tasks by decreasing order of WSJF.
At the end of the sprint, just as we track the story points we completed with the velocity, we could track the business value we created, that would be our business value speed. If you have access to real sales numbers, it might be interesting to see if it’s possible to correlate the figures.
Afterthoughts
The more I learn about Lean principles, the more I find our current Issues Tracking Systems (I’m used to Jira) limited. They seem to be databases with a nice UI, whereas what we need are tools to help us to make better decisions out of the multitude of items … How come they do not provide something as simple as the WSJF ?
Edit 12/09/2014
I got some pretty positive feedback from practicing these business value pokers. Inviting the product owner forced him to explain in details why he believed some features were more valuable than others. On the opposite, it allowed the developpers to hightlight how some seemingly unimportant stories were critical to a long term goal. In the end, everyone, including the product owner, is asking for more. It’s a good practice that helps introducing the business value / cost of delay concept.
This was part 3 of my suite of article about Lean Software Development, Part 2 was Why eXtreme Programming works ?, Part 4 will be Measure the business value of your spikes and take high payoff risks.
Leave a comment