Skip to main content

Home/ Agilesparks/ Group items tagged estimation game

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Yuval Yeret

James Shore: Value Velocity: A Better Productivity Metric? - 0 views

jamesshore.com/...etter-Productivity-Metric.html

agile roi productivity

shared by Yuval Yeret on 24 Jun 09 - Cached
  • *Please note that I'm specifically talking about productivity. Velocity is a great tool for estimating and planning and I'm not trying to change that. It's just not a good measure of productivity.
  • rather than asking your business experts to measure business value after delivery (difficult!), have them estimate it beforehand. Every story (or feature--keep reading) gets an estimate before it's scheduled. At the end of each iteration, add up the value estimates for the stories you completed in that iteration. This is your "value velocity."
  • And rather than reflecting the hours programmers work, as cost velocity does, value velocity actually reflects productivity. Remember, productivity equals output/time. Value estimates are a much better indication of output than cost estimates are.
  • ...7 more annotations...
  • It's like traditional velocity, except it's based on your customers' estimates of value rather than your programmers' estimates of cost.
  • stories don't always have value on their own.
  • Although value velocity isn't perfect, a team with consistent value estimates would be able to graph their value velocity over time and see how their productivity changes. This would allow them to experiment with new techniques ("Let's switch pairs every 90 minutes! Now once a week!") and see how they affect productivity. If balanced with actual measures of value and some sort of defect counting, this could be a powerful tool.
  • just estimate and score features rather than stories.
  • Another option would be to pro-rate each feature's estimate across all of the stories required to deliver it.
  • some types of stories don't provide value in the traditional way. What's the value of fixing a nasty crash bug?
  • Third, value velocity is just as vulnerable to gaming as cost velocity is... perhaps more so. I'm not sure how to prevent this.
Yuval Yeret

InfoQ: What is Velocity Good For? - 2 views

www.infoq.com/...velocity-value

agile velocity

shared by Yuval Yeret on 09 Jul 09 - Cached
  • Doubling velocity (story points done-done in each sprint) usually means we must improve several things:
  • a clearer definition of done
  • no [known] bugs escape the Sprint
  • ...6 more annotations...
  • we must prioritize the impediments, and keep removing or reducing the top one until velocity is doubled
  • Hint: We might want to prioritize the impediments by how much the removal/reduction will increase velocity. 25% here, 30% there; pretty soon you're talking a real increase in velocity.
  • Hint: Improving quality and reducing technical debt are almost always important keys to seriously increased velocity. Not the only keys, but very important.
  • Velocity is best used for long term planning. I can look at my velocity over several iterations and come up with an average (Preferably a range.) Then I can use that information to say things like: 1) Given the current backlog, how many iterations is it likely to take to complete a given set of stories? 2) How many story points, and by extension what set of prioritized stories, can I deliver by date X (e.g. in time for the trade show?)
  • I am very wary of anyone who suggests increasing velocity is a goal. *They are just estimates*. It is so easy to game. I've seen it happen both consciously and subconsciously with very undesirable effects.
  • The only measure of increased productivity is completed work. Measuring this also has the desirable side effect of encouraging people to break work down into the smallest possible deliverable units.
1 - 3 of 3
Showing 20▼ items per page