July 4th, 2009Velocity gone wrong #2: Making up points
Continuing with the series on how to misuse velocity, the second anti-pattern I would like to highlight is when teams start making up points. Because the definition of velocity is so simple, it’s easy to game the metric to show what looks like apparent progress. If a team is being measured on velocity (more about this on later posts), it’s quite easy to just start increasing estimates: “If we just double all estimates, the relative sizes stay the same, but our velocity doubles!“. This is an extreme behaviour that would be quickly noticed as a discrepancy, but the same thing could happen in a smaller scale and pass unnoticed.
This problem can not only be originated from the team, but I’ve also seen Project Managers/Scrum Masters coming up with “clever” ways of making up points to count as velocity:
- Counting percentage or half points (as mentioned in my previous post)
- Deciding to split a story to count the partially finished work as complete, and track whatever is left in a separate story (splitting should be business-driven and not tracking-driven: it should only happen when you come up with simpler/incremental ways of delivering value in smaller chunks)
- Counting points on technical tasks. I’ve seen a team that spent a lot of effort in an iteration to make up for accumulated technical debt, and did not have a lot of time to work on new stories. The Project Manager decided to come up with a “refactoring card” and gave it a 16 to try and demonstrate how much effort was spent on such refactoring
- Counting points for in-release bug fixing. In a team, stories were deemed completed on the first iteration, but bugs started to show up in later iterations, impacting he team’s ability to deliver new functionality. Instead of allowing the decrease in velocity to demonstrate how the lack of focus on quality was impacting the team (bugs should be prevented in the first place, right?), the Project Manager decided to estimate and count points on bugs, which kept velocity apparently constant, when in fact a lot less value was being delivered
The next time you catch yourself asking “Should X count as velocity?”, stop, reflect, and ask instead “Should I worry about X happening at all?”. If you are worried about having to track or show progress on things that should be embedded parts of the process (such as activities to prevent bugs or refactoring), chances are that the problem lies somewhere else. Some of these questions might make as much sense as “Should time spent on retrospectives count as velocity?” or “Should going to the bathroom count as velocity?” :-)
I’m sure that these examples drawn from my personal experience are just a few examples of how to make up points and misuse velocity. What other similar experiences did you have in your own projects?
Twitter
LinkedIn
Facebook
Flickr
Github
July 5th, 2009 at 2:27 am
Agree with all your points except for bugs. Bugs found on accepted cards should be estimated and count towards velocity because fixing a bug in itself has business value and can be prioritised against other story work. Fixing a bug is not “free”. Is fixing Bug X more or less important than delivering Story Y? It’s the business’ call. To make that decision they need to have an idea of the effort involved in fixing the bug, hence the need for an estimate.
Having said that, if you have lot of bugs found after stories are accepted then it’s a symptom of something going wrong in the development process which needs to be addressed.
July 5th, 2009 at 9:53 am
I actually think that technical stories should have points. There should be a business value to each technical story played, otherwise there is perhaps no point in playing them.
Stakeholders should be able to prioritise new work over technical issues and I don’t see that really being possible without using comparable scales of effort.
If no-one can put business value on the technical task then arguably there is no technical issue at all, just the natural desire to fiddle with things to make them more intellectually or aesthetically pleasing.
July 14th, 2009 at 10:32 am
Tomas,
I agree and disagree :)
Our industry has somehow grown accustomed with the fact that software contain bugs, and that’s acceptable. We need to change that view. Our customers shouldn’t have to prioritise bugs because they shouldn’t be being introduced in the first place. I’ve been in well performing teams that didn’t have to prioritise or estimate bugs because the number was so low that they could ‘absorb’ that as part of the normal day-to-day work, without impacting velocity (or raising concerns about tracking points against them). I know that’s an idealist view of the world, but it’s something we have to work to change (as you said, if you have lots of bugs then it’s a symptom of something else going wrong)
Having said that, if your team is doing only support work, then it’s probably mostly working on bugs, and then it might make sense to estimate/prioritise them. But again, this is work towards failure demand, which is considered waste in Lean. I guess you have to judge the merits of it based on your context.
July 14th, 2009 at 10:38 am
Rob,
I agree that business should be able to prioritise new work over technical issues, but I think technical stories should be driven from a business need, rather than the other way around. Accumulating technical debt and then later asking the business to pay for it is not a professional approach.
July 14th, 2009 at 9:58 pm
[…] performance measure. Quite the opposite, it’s a very easy metric to game (as mentioned in my previous posts). When approached as a performance metric, it’s common to see things […]
August 1st, 2009 at 7:43 pm
“Our industry has somehow grown accustomed with the fact that software contain bugs, and that’s acceptable. We need to change that view.”
Yes… and no. If we agree that the decision to release a software product is a business decision then I posit that the view will never change as business forces (e.g. time to market, a trade show, etc.) drive release decisions.
“Our customers shouldn’t have to prioritise bugs because they shouldn’t be being introduced in the first place.”
First, I believe that depends on your definition of ‘bug’. Is a deferred requirement or de-scoped feature a ‘bug’? If so, clearly the effort to develop that piece of functionality should be explicitly scoped, estimated, prioritized and tracked.
Secondly, avoding self-referential decision making is a lesson I revisit with teams over and over. Which is why I love the emphasis agile methods place on a close working relationship with the business owners. As members of the product development team we may have a good idea of how to prioritize our work, but ultimately it is the person writing the check that should tell us what they need and want.
“I’ve been in well performing teams that didn’t have to prioritise or estimate bugs because the number was so low that they could ‘absorb’ that as part of the normal day-to-day work, without impacting velocity (or raising concerns about tracking points against them).”
My lawyer charges me for every minute worked (including responding to my e-mails). So does my CPA. The same can be said for lots of other industries. Why do we as practitioners in the software industry continue to perform work and then hide it? No wonder that business owners and stakeholders continue to question what we are working on. We don’t give them nearly enough visibility into our efforts!
April 19th, 2010 at 10:58 pm
[…] teve com Priorização Desnecessária durante o penúltimo sprint. Ser ágil é entregar valor, e seus pontos estão sendo utilizados em funcionalidades completas sem tanto valor. Se existiam outras tarefas que entregavam valor para os usuários, a priorização poderia ter […]