On mistaking speed for getting what you need
It’s a known fact that even though Scrum is a simple methodology, its simple concepts are frequently misunderstood. So, let’s mix the aforementioned quest for a software productivity measurement with those misconceptions around Scrum, and what do you get? Answer: the use of Velocity as a productivity measurement.
Using a single number (like Velocity) as a measurement of a team is plain wrong for several reasons:
1 - It’s very easily cheatable - inflate your estimates in story points, add water and… voilà: higher Velocity.
2 - For starters, Velocity doesn’t ever tries to measure productivity. Velocity is an agile planning tool! It tells us, as a team, how many story points we can “burndown”, on average during a sprint. Therefore, it helps the team to get an idea of what they can commit (roughly) on a Sprint Planning. So, let’s use Velocity for it was intended: to help us plan.
In my opinion, this focus on measuring productivity is misplaced. Let’s use that energy in measuring return of investment, on post-controlling the projects we delivered - in short, in analysing the true results of our finished product… instead of obsessing over an abstract number.
If you parachuting from a plane, you can cut the strings to the parachute in order to go faster - but will you get the desired results in the end?
Hola Ricardo,
Arrived to your blog from Nathan’s one. Good entry.
Recently I was reading in another Agile Blog about velocity / productivity. In that blog somebody mentioned a sentence by Paul Hodgetts, Agile Coach and Certified Scrum Master:
“Velocity is more of a quantity of work completed metric. Useful and important, but not the sole measure of success. I think you would want a set of metrics that together help us understand our current capabilities to deliver as well as if those capabilities are changing from one point in time to another. I don’t believe there is one magic “agility number” to measure [productivity].”
You seem to take it one step further. More than productivity, it is important to concentrate on ROI or value. Agreed. You say that it is important not to focus on an abstract number, but measuring the value after releasing is sometimes even more difficult to quantify.
How do you suggest we can tackle this? at the end of the day, we need to “quantify” in one way or another, the results of the project. Even if it is to show senior management.
Thanks!
Marta
Marta Padilla
10 Jul 09 at 17:07
Hello Marta,
The quantification which you mention here is something totally different from what I was refering to - what you are talking about is the post-controlling phase of a project, i.e., the project is released and now we need to measure its value.
I agree with you, post-controlling is difficult, and I don’t have a definite answer for that one - because it depends on the project itself (i.e. boxed software vs online service, commercial vs defence software, etc.). Most probably would be senior management (or the product owner of the project in question) that needs to tell what are the parameters against which the success of the project should be measured. I am sorry for not being able to help you more with this one, and thanks for commenting :).
Ricardo Mestre
19 Jul 09 at 20:07
Well, we don’t have all the answers. That’s why blogs like yours are so helpful. They provide good ideas and a good forum for discussion!
Will keep reading….
Thanks!
Marta
Marta Padilla
22 Jul 09 at 11:07
Sure, you’re welcome!
admin
22 Jul 09 at 14:07