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\u2019m broke, $10 can be a lot. If I\u2019m rich $1,000 may not be of any value. If I\u2019m 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.<\/p>\n
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.<\/p>\n
The numbers most often used in Scrum<\/a> 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.<\/p>\n 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.<\/p>\n The sprint is where time and cost merge. If you\u2019ve assigned a price for each story point<\/a> 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.<\/p>\n Typically traditional project management methods\u00a0roll budget calculations upward following these rigid steps.<\/p>\n Agile offers the opportunity to create\u00a0budgets based on key performance\u00a0benchmarks. These numbers\u00a0are derived\u00a0from 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\u2019s worth of three week sprints (17) costs around $864,000. If your team embraces the improvements identified during the retrospectives<\/a>, the actual cost will very likely be less.<\/p>\n Don\u2019t 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 \u2026<\/p>\n Traditional budgets and schedules are not viewed\u00a0as dynamic. Using the\u00a0cost per story, story points per sprint\u00a0and the length of sprints as benchmarks, Agile\u00a0offers\u00a0an opportunity to view numbers and time in smaller more manageable\u00a0units. This gives\u00a0organizations 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.<\/p>\n Resources used to create this example:<\/p>\n What do you\u00a0value? 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.<\/p>\nBenchmarks vs.\u00a0traditional\u00a0time and cost<\/h2>\n
\n
\n
\n