Pete Douglass and Karl Chambers are Scrum Masters and recently found themselves dissatisfied by projects that they'd worked hard on but were (a) taking a long time to get anywhere close to deployment, (b) being delayed by late-breaking feature requests, (c) both of the first two, and (d) not fazing the business at all.
As they saw it, the business likes to see its people getting on and doing stuff. If using Scrum, the business typically likes to see a consistent or upward-trending velocity for its teams: more work being done. The business will often not differentiate between between a simple proxy metric and the thing they'd really like to measure, between work done and value delivered, between outputs and outcomes.
In their talk at last night's Cambridge Agile Exchange Pete and Karl described a couple of ways they tried to help the business side to see that having busy development staff wasn't the same, or even directly related to, the delivery of business value.
The first approach was the cost of delay, what the business would lose by waiting for a new feature before shipping. They considered specifically the revenue not achieved during the delay, but there are other factors that could be interesting too, such as the company spends more on development costs, the market changes and the company loses competitive advantage, or the business misses out on a chance to learn something from customers.
Depending on the richness of your data and the maturity of your business analysis, you might need to put fingers, hands, or even whole arms into the wind to get values for those things but the relative cost vs return can be shown to some approximation. Karl and Peter didn't use these terms, but in lean approaches unshipped product can be viewed as inventory and hence waste with no or even negative business value.
The second thing they tried was to attach business value points (BVPs, a relative measure, analogous to story points, in a Fibonacci-style range) to each of their stories. In this experiment they discovered that around 50% of their stories were ranked as having zero business value, and the majority of the rest sat firmly in the middle of their scoring range.
I'd have liked to have heard more about the way in which BVPs were assigned. There are potentially very interesting granularity effects at play when trying to slice a value-bearing project into small pieces. To give an example, "test stories" were said to be zero value.
Perhaps in some sense they create no customer-consumable artefact such as a piece of software or a service and so they truly do deliver no value? Or perhaps they create sufficient confidence in the PO that the product can be released, and so are a keystone in the value? If there was no value in those tasks, why do them? The fact that the team decided to abandon the stories, but still do the work inside the "dev stories" suggests that someone who matters perceives there is value in that effort.
Another angle to consider is temporal. Tasks done today might have no immediate value to customers but could be preparing the ground for some later work which will. When can that value be credited to the work? Under what circumstances? I've written about this before in Quality != Quality. There are other kinds of dependency too. With further analysis, the stories that were scored at 4 BVPs (the mid-range ones) were typically dependent on other stories, and could only deliver value when deployed together.
Approaches to the quantification and quantisation of value is a topic that interests me greatly and a question along the lines of "can we assign a value to the pieces of work, and prioritise and order work such that we deliver the (perceived) most valuable pieces at the (perceived) most valuable times?" is a good one.
Ron Jeffries asks it well in his reflections on story points, which he fears he may have named:
First, think about one or a few important capabilities for the next release. Talk about what the problems are that they solve, and what software might help solve them ...
Second, think about a close-in deadline such that you feel you could get some good capabilities built by then. Set the deadline and get to work ...
Third, slice off thin slices of the important capabilities and do them. You should be able to get them down to a day or less pretty easily. Work only on the most important next bits ...
We want to make the value of what we’re doing so visible that our Product Owner and other stakeholders can’t wait to get it out there.
Comments
Post a Comment