This can easily lead to some very nasty scenes where the Scrum Master demands that the Product Owner produce a "value" for each story—actually write a number on the card. The problem comes to a head when it turns out that the Product Owner not only doesn't know the value of the stories they are putting on the backlog, but they also have no way of finding out what they value of a story is. And this isn't because they are stupid, nor incompetent, nor malicious. It's because finding that value is far, far too difficult and time consuming an activity. And there's a good chance that any answer that came out of it would be so well hedged as to be meaningless.
Sometimes the Product Owner does know, or can find out at reasonable cost, a value for a story or feature. Being able to trade a new asset class probably can be valued. Changing a flow to give 10% high conversion probably can be valued. Improving a model to get 1% higher efficiency in the machines it's used to design can probably be valued. These valuations will be functions of time time and various other parameters. If you really have to, you could get a number of them that's valid today (and perhaps only today). David makes the point that even if you do know that number for a feature, scheduling the next one simply on the basis of highest value might not be the smartest move. There are other variables to consider.
There is a case to be made that within the context of a project value isn't the best figure of merit to use anyway, since someone should have made a go/no-go decision at some point that the planned budget and planned value seemed reasonable. That decision should be re-assessed frequently (far too little of this goes on) based on progress to date, and action taken if the actuals have come too far adrift, but in-between those times trying to optimise on value is perhaps not worth it.
Another option is to indeed demand (and obtain) those value numbers and then schedule work primarily on the basis of business value and dispense with effort estimates, so-called "naked planning". This has caused eyebrows to be raised. The underlying claim is that
value varies along an exponential scale while development costs vary along a linear scale. Therefore delivering the most valuable features trumps any consideration of whether or not the most valuable feature is cheap or easy to developwhihc, if true of your environment, might give pause for though. How this interacts with the desire to schedule so as to maximise throughput at the bottleneck is an open question, for me at least.
3 comments:
Thanks for the mention.
I think that there's much to be said for not estimating effort at all - the numbers you get for estimates are often highly suspect and highly padded. Making them more accurate takes time. I've been on a team where the developers were actually encouraged to go through the source code and work out exactly which lines of code will need to be changed and added, before coming up with a "highly accurate" estimate. Then half the time someone else ended up implementing the story later on and did it a different way. :-)
Estimation is a vexed subject.
It is possible to come up with surprisingly good estimates quickly and cheaply—the important thing is to be aligned with McConnells' guidance: “The primary purpose of software estimation is not to predict a project’s outcome; it is to determine whether a project’s targets are realistic enough to allow the project to be controlled to meet them”
I strongly suspect that the emphasis put on estimation (and on the "accuracy" of estimates, usually defined as closeness to the actual) is a sign of an institution that doesn't trust its development team—often with good reason. What I aim for in my consulting practice is to get that trust back, sometimes using some hard-core estimation and close management and then progressively drop back to less and less sophisticated estimation. I see it as a transitional practice, on the road from low trust to high trust.
Agreed: it is far easier to say "prioritise by business value" than to actually do it. Putting a value on a feature/story/task isn't easy.
There seems to be three fairly common ways of prioritising:
- by value (including "juicy bits first")
- by risk
- by cohesion (stuff which fits together)
And I've heard of all sorts of fancy prioritization approaches and formula
But for me the important thing is: It gets prioritised by someone with a business hat. Leaving it to developers is an abdication of responsibility by the business side. If they do this they loose the right to complain something was not done.
Second: once prioritised you can hold it firm for more than a few hours, hopefully a few days and ideally till the end of your iteration.
So, anyone who is likely to come along and change the prioritisation needs to be part of the process.
And if you really can't hold things constant for that long, then you should be using a Kanban-like system and re-prioritizing every day.
Post a Comment