Skip to main content

Home/ Agilesparks/ Group items tagged agile-roi

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Yuval Yeret

How to make a LOT more money using agile - 0 views

www.agileforall.com/...e-a-lot-more-money-using-agile

agile roi agile-roi

shared by Yuval Yeret on 04 Jun 09 - Cached
  • How to make a LOT more money using agile
  • More frequent releases
  • expectations must be set for releases to be smaller but still have significant marketable value.  It also means managing scope for smaller releases so the value can actually be delivered to meet the expectations.  If we make the assumption these two pre-requisites can be handled, then we can also assume faster releases are possible.  Yes, I know, releasing software is expensive, requires other groups, etc.  For now, let’s assume all of those costs are negligible compared to the potential results and see where we end up.
  • ...14 more annotations...
  • team of 8 people work on a project for a year with an anticipated ROI of 100% after 2 years.
  • $1,000,000 (approximately) in 12 months to build the product
  • get $2,000,000 in revenue within the 12 months following release.
  • ROI is calculated as $profit/$invested which in this case is ($2,000,000-$1,000,000)/$1,000,000 or 100%
  • cash expended, which in this case exactly matches the investment since we did all of the investment prior to receiving any return.
  • Let’s assume that scope can be managed so the product can be delivered in two phases, each taking 6 months.
  • each piece of the product is worth about half of the revenue value of the complete product
  • 6 months at an investment of $500,000 to build the first piece
  • 6 more months at an additional cost of $500,000 to complete the second half
  • after 6 months revenue starts to be brought in for the first release
  • the amount of revenue during the first 6 months of release of the first half of the product would be $500,000 ($2,000,000 for full product for 12 months = $500,000 for half product for 6 months).
  • matches the cost for building the second half of the product, so the cash expended is actually only $500,000 for building the product vs. $1,000,000 for building the product in one step.
  • After phase 2 of the product is completed it too starts to bring in revenue.  We now have the complete product, so we can get full value of it during each time period.  In other words, during the next 12 months it will generate $2,000,000 in revenue.  This brings total revenue to $2,500,000 which means our ROI is now 300% (higher profit divided by smaller investment - $1,500,000 profit / $500,000 invested).
  • Month Expense Revenue Cash (Profit) Total Revenue 6 $500,000 $0 -$500,000 $0 12 $500,000 $500,000 -$500,000 $500,000 24 $0 $2,000,000 $1,500,000 $2,500,000
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.
1 - 12 of 12
Showing 20▼ items per page