What do you value?
Numbers and time are interesting. They have no value in themselves, but success is constantly measured by them. Sports teams, businesses, families and even religious organizations have their set of sacred numbers and times. Either is simply the representation of value. If I am hungry two apples are more valuable than one. If I’m broke, $10 can be a lot. If I’m rich $1,000 may not be of any value. If I’m in a hurry 10 minutes can mean a lot. If I have plenty of time on my hands, an entire hour does not mean much.
Determining the value of a product and when it will reach the market can be quantified in many ways. The first step is identifying exactly what it is you value. When it comes to producing goods, including software, the two values most often estimated, are when the product will be done and how much it will cost.
How does scrum express value?
The numbers most often used in Scrum are represented by either story points or product backlog items (stories). These are in effect your activity estimates, but initially not related to time. I usually prefer story points. They are the lowest common denominator and easily express small variations.
The second important Scrum value reflects time. Agile Scrum uses time boxes, expressed as sprints, and not schedules. Keeping this in mind will save a lot of trouble. It is important to remember, time like numbers, is only an expression of value.
The sprint is where time and cost merge. If you’ve assigned a price for each story point it is easy to accurately report the cost of specific features finding their way into the product. This in turn sets a financial expectation on the increased value of the product. The trouble is, at this point we only have the cost of one sprint. How about calculating costs for an entire year? This is where our benchmarks come into play.
Benchmarks vs. traditional time and cost
Typically traditional project management methods roll budget calculations upward following these rigid steps.
- Estimate activities
- Calculate work package estimates
- Calculate control accounts
- Calculate project costs
- Calculate contingency reserves based on risks
- Calculate cost baseline
- Calculate management reserves
- Arrive at budget
Agile offers the opportunity to create budgets based on key performance benchmarks. These numbers are derived from team performance and can easily be adjusted as improvement goals are met. If you know your team can usually complete 240 story points per sprint and each story point costs $300 you can project that value forward for an entire year. Based on the preceding example, a year’s worth of three week sprints (17) costs around $864,000. If your team embraces the improvements identified during the retrospectives, the actual cost will very likely be less.
Don’t overload your calculations with too many benchmarks. Remain focused on what you really need to know. These are usually production costs and time to market. To calculate this, all you need to have is the …
- Cost per story point (cost)
- Average or median story points per sprint (throughput)
- Length of each sprint (time)
Traditional budgets and schedules are not viewed as dynamic. Using the cost per story, story points per sprint and the length of sprints as benchmarks, Agile offers an opportunity to view numbers and time in smaller more manageable units. This gives organizations accurate up to date information as to the health of their projects. If your goal is to accurately calculate the time and cost involved in getting a product to market, basing these on benchmarks instead of a static set of numbers sounds like a pretty good idea.
Resources used to create this example: