3

We do Scrum - therefore we do not estimate hours or workdays, but estimate complexity (Story Points).

As our customers mostly want to know what a feature might cost, we somehow have to do a conversion from complexity to money. In a big project with several stories for one customer (it seems this is the use-case mostly described) the strength of Scrum is uncertainty and the ability to change priorities after every sprint. In our case most enterprise customers only "buy" on feature for an application, so there is no "balancing" over time.

My question is, how to deal with such use-cases? How do I convert our estimations to an amount which our customers are (hopefully) willing to pay for? How do we reduce the risk of uncertainty in our estimations?

2

You need three values to forecast a cost: Speed of the team, estimate from the team and the cost of the team. Leading to a formula like this:

FeatureStoryPoints * (TeamCost / AverageVelocity) = Estimated Price

  • AverageVelocity: For speed you could take the average velocity (yesterday's weather) of a team. Do calculate capacity and normalize the velocity for each sprint.

TeamCapacity% = ActualHoursAvailableForThisSprint / ContractHoursOfAllTeamMembers

NormalizedVelocity = SprintCompletedStoryPoints * TeamCapacity%.

AverageVelocity = (NormalizedVelocitySprint1 + Sprint2 + Sprint3) / 3

  • FeatureStoryPoints : For the estimates you could try to make the stories really small as it reduces uncertainty. With a list of small estimated user-stories in story-point you can forecast how many Sprint it would cost to complete the stories. Practise stories splitting. Let the full team estimate and discuss to get all the uncertainties on the table.
  • TeamCost: For the cost you take the full cost of the team and calculate what the team costs per Sprint. Do take all the costs into account, not just salaries. E.g. vacation days, training, sick-days, over-head people (HR, managers, etc), building costs and materials. Know what your team costs per Sprint.

So technically you could come up with an average cost per story-point, just make sure you re-evaluate the velocity and costs as teams change this metric will change as well. Also do not re-use old estimates, clear them and use the new info from the last iterations to re-estimate continuously.

For fixed prices I would always add a good margin so you do not get into trouble. Communicate this to your clients. I mean telling them that a non-fixed price would probably be cheaper most of the times.

Do think if you want to sell features clients think they need or how you can help them finding the impact or behavioural change they need to grow their business. Selling an Agile way of working might be more interesting long-term than just selling features.

  • Thanks for your valuable input. What would you advise: How often should I recalculate the AverageVelocity and how long into the past? – ppasler Jun 2 '17 at 8:20
  • 1
    Our team uses yesterday's weather, which averages only the last three Sprints, but in the book "This is Agile" Sander suggest to average the whole project. You might need to normalize the velocity with capacity as you need someway to compare sprints to each other where people are on vacation or have other work. I forgot to add this. – Niels van Reijmersdal Jun 2 '17 at 8:33
  • 1
    We update it at the beginning of the Sprint planning meeting as we use it see how many story-points we will pick-up this Sprint. So we always have a AverageVelocity number available. The estimates are harder to keep update if you plan to much Sprints ahead. – Niels van Reijmersdal Jun 2 '17 at 8:40
  • Thanks again, this is not only useful for talking to customers, but a valuable information for ourselves :) – ppasler Jun 2 '17 at 8:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.