10 tips on how to prevent business value risk
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Dan Puckett on Sep 02, 2010
In a recent thread on the Scrum Development mailing list, Paul Battison asked whether his team should re-estimate completed stories after the sprint is done, so as to have the team's velocity reflect the actual effort that went into completing the stories.
The rough consensus? Don't rework your estimates on completed stories.
On consideration, it's hard to find a lot of value in the practice of re-estimating stories once they are complete. Kelly Waters explains why:
The beauty of Velocity is that statistically it compensates for bad estimating. The consequences of unplanned tasks—e.g. a user story being estimated at 3 points and turning out more like a 13 in reality—is that the team still only scores 3 points for it. The consequence of this is that the team's Velocity is lower than expected, meaning that the team plans future Sprints based on a more realistic target, with the team's actual Velocity being based on what they had thought when the user stories were estimated.
Over the course of several sprints, a team's velocity will therefore naturally adjust to accomodate story estimates that are habitually too low or too high. The velocity will become more accurate on its own—no need for special post-facto adjustments to bring it into line.
Indeed, adjusting the estimates of completed stories is more likely to be harmful than merely useless. Paul Oldfield writes:
[...] if you adjust the backlog your existing velocity is thrown in doubt. How important is it that you need to predict well over the next few iterations? It may take that long to get back to a velocity that is reasonably reliable.
The point of making estimates of stories is to determine the team's velocity. What is velocity? According to the Scrum Alliance, "
In Scrum, velocity is how much product backlog effort a team can handle in one sprint." Tweaking estimates after-the-fact reduces the predictive ability of velocity for future sprints by mixing story estimations made before sprints with "estimations" of stories made after sprints are complete. Comparing and reasoning between these two types of estimates is very difficult to do—perhaps impossible.
Should you never re-estimate completed stories? Almost never, but there are exceptions. Mike Cohn writes:
Generally re-estimating is useful when you completely blew it on the original estimate and can see that the mistake was a rare occurrence. (That is, if every estimate is systematically off by half I wouldn't re-estimate.) Second, you should re-estimate when there has been a change in relative size. For example, the team has discovered that learning AJAX will be about half as hard as they thought. We'd want to fix that because the new knowledge tells us that our relative estimates are off-kilter for the AJAX-heavy stories.
In general, though, it's best not to change the estimates for your team's completed stories. There is a powerful impulse to fix those estimates based on what you know now, but in most cases, that impulse should be resisted.
Transforming Software Delivery: An IBM Rational Case Study
SCM best practices for multiple processes, releases & distributed teams
A practical guide to choosing the right agile tools
agility@scale eKit: 10 Principles, Scaling Model, Metrics, Collaboration
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
Postmortems are good if the scrum is ready to learn from their mistakes. There is no point in resizing unless we figure out why the story was undersized in the first place. If the resizing exercise helps the team in avoiding mistakes in the future the scrum should do it.
If the scrum is resizing every iteration then there is something wrong with the process.
Raghuveer makes a good insight, that resizing as a postmortem activity can help the team estimate better in the future. I love that idea. For many teams, that exercise seems worth doing.
But, for the many reasons mentioned in the article, going back and adjusting the velocity based on those new numbers does not feel justified. It would be a bit of a cheat.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
Sean Cribbs explains what Map-Reduce and Riak are, why and how to use Map-Reduce with Riak, and how to convert SQL queries into their Map-Reduce equivalents.
2 comments
Watch Thread Reply