Story point based cost estimation

From all backlog items, the Epic is the most interesting in our use case, because we try to
model features into epics. One epic or the sum of a few epics are the whole project costs. If
your backlog model looks a bit different, the formula introduced below is pretty easy to
adapt.
The formula to estimate the costs for an epic is:

First, we compute the costs of one story point. This is done by multiplying the number of
man-hours in a sprint with the average salary per hour, which corresponds to the total
costs of a sprint. Then we divide this by the average velocity of the last few sprints, which
gives us the costs of one story point. Important here is that we only take the last few
sprints to calculate the velocity because the average velocity tends to change over time.
To get the final costs of an epic, we multiply the number of story points in an epic with the
costs of one story point.
Lets play this through with a toy example - note that the following numbers are for
demonstration purposes only. Imagine we want to compute the costs for the epic "Super
Feature", which is distributed over two sprints.
To compute the costs for that epic we need a bit more information which is given in the
table below. The numbers are just some random example numbers and do not represent
a real development team at G DATA.

Story points in epic "Super Feature"

Number of developers- 4

Weeks per sprint- 2

Average salary per hour-35Euros

 Average velocity-72

Story points in epic "Super Feature"-99

If we use the formula from above and insert all the values we get the costs for the "super
feature" epic.

The costs for the epic "super feature" are estimated at 15400€. Keep in mind that this
number only reflects direct development costs. Other costs, like hardware, licenses or the
planning of the epic itself are not part of the equation. This means that the costs
computed here are only a lower bound and the additional costs should be added to get a
more precise result.

Burn Rate Cost Approach

The first approach is to work with your sprint session burn rate and period.
Considering the sprint session has a fixed number of time resource units, it
can be simple to work out the true cost if the cost of each resource is
obtained. Depending on what costs are available to you, the approach can
either be:

• Average cost per person per hour. This is the simplest approach
as you multiply the hours of each resource utilized during the sprint
by the average cost you have been supplied. As an example, if
you have one part-time resource and one full-time resource at
$100 an hour (assuming 8 hours a day), a two week sprint would
be (40 hours x $100) + (80 hours x $100) giving you a $12 000 per
2-week sprint cost.
• Specific cost per person. This approach would require some
additional calculations, where you will need to derive an hourly
cost per person based on their annual salary cost. Once you’re
down to an hourly rate, the calculation is the same as average cost
per hour.

While this budgeting is a straightforward approach, its major challenge or

downfall, is that it is heavily dependent on calculating the correct burn-down
rate or scoring each agile task accurately. It also requires the tasks to have
been estimated before you can turn the sprint cost into a project or solution
cost. This only solves one part of the problem.
Another issue is that it doesn’t solve for the additional costs outside of the
sprint planning. You will need to extend your costing model to provide for
testing hours, administration hours, meeting hours and design hours.

Precision-alignment approach
Another approach is more budget orientated and less estimation orientated,
and requires a set of business outcomes that are prioritized. Let’s assume
you’re building an online retail shop for clothes. This business requirement
can be broken down into a handful of areas that translate to major solution
tasks, such as:

• A landing page for marketing

• A search function
• A checkout function
• Product pages
• A customer knowledgebase
• Order management system for customer agents

The next task is to then estimate, based on previous experience or some

guidance from developers, what each task would take:

Task Time Budget

Store landing page 2 - 4 weeks $20k - $40k

A search function 4 - 6 weeks $40k - $60k

A checkout function 6 – 8 weeks $60k - $80k

Product pages 3 – 6 weeks $30k - $60k

A customer knowledgebase 2 – 4 weeks $20k - $40k

Order management system 4 – 8 weeks $40k - $80k

This gives a first-sweep budget range of $210 000 - $360 000. Despite this
wide range, the business can already make a decision if the minimum budget
exceeds the resources available for this project, or is way under resources
available. If the range is too broad for the business, you continue with the next
step.

Take all the tasks, and assign a priority to each one, which allows a distinction
between ‘must haves’ and ‘optional maybes’:
 Task Time Budget Priority

Store landing page 2 - 4 weeks $20k - $40k 5

A search function 4 - 6 weeks $40k - $60k 3

A checkout function 6 – 8 weeks $60k - $80k 2

Product pages 3 – 6 weeks $30k - $60k 1

A customer knowledgebase 2 – 4 weeks $20k - $40k 6

Order management system 4 – 8 weeks $40k - $80k 4

As the business assigns a ranked priority, it then reveals that some items may
be optional, and it also illustrates which items need a more-specific cost
estimation. In this hypothetical example, the top 3 priorities receive more
attention resulting in a budget that is of a tighter range:

Task Time Budget Priority

Store landing page 2 - 4 weeks $20k - $40k 5

A search function 4 weeks* $40k 3

A checkout function 7 – 8 weeks* $70k - $80k 2

Product pages 4 – 5 weeks* $40k - $50k 1

A customer knowledgebase 2 – 4 weeks $20k - $40k 6

Order management system 4 – 8 weeks $40k - $80k 4

* displays the revised time estimation

The revised timings and cost now provide a more acceptable budget range of
$230 000 – $330 000. This budgeting process takes substantially less time
(completed in a day) and provides business with enough data to not only
make a decision to go ahead, but a budget to manage the project.