Accounting for design, discovery and analysis activities in Scrum project budget forecasts

Question

Consider this scenario:

Backlog: 100 story points, project budget $100,000 (based on past team velocity/cost of delivering 1 SP per $1000 time spent). Stories are based on product development.

Week 1: Budget spent $10,000, 0 SP delivered Intensive UX design activities, refining the backlog, development setup

Week 2: Budget spent $10,000, 10 SP delivered Development starts, refining the backlog

Week 3: Budget spent $7,500, 10 SP delivered Development continues, refining the backlog

Week 4: Budget spent $12,500, 10 SP delivered Development continues, refining the backlog, intensive stakeholder workshop activities around later epics (approx. $5,000)

Cost to date is $40,000, we've delivered 30 story points. How do you forecast the cost to deliver the remaining 70 story points?

Applying a straight calculation: current project costs $1,333 per SP delivered so 70SP x $1,333 = $93,333 to go, meaning $133,333 total cost. But this doesn't account for the fact the UX design and workshops required early in the project have completed and the development team is delivering faster than anticipated.

Is there a common, recognised method to forecast remaining cost for Scrum development projects that accounts for surrounding design and analysis activities?

Answer 1

This is a tricky question to answer, usually the cost of a scrum team is sunk regardless of the value delivered at the end of each sprint. i.e. if the team were to achieve nothing then you'd still incur salary & overhead costs.

If you apportion costs over the sprint cycles and manage Story points separately it would make more sense.

Linking Costs to Story points would appear to be beyond Scrum.

But this doesn't account for the fact the UX design and workshops required early in the project have completed and the development team is delivering faster than anticipated.

Agreed. But then you have to account for implementation costs and post implementation support too, if the dev team is delivering faster then expected, this is great, it means you'll have more time to consider and prepare for putting your software live. Again this supports the view that Story Points should not be linked directly to Costs. The PO or Project Manager (if you have one) will have to constantly monitor the teams delivery to ensure that they have completed enough work to meet the definition of done in time for pre-implementation activities to be completed.

Answer 2

As with all estimates I think you should provide a range and some confidence numbers as well.

For example:

Using your previous formula of 1000$/sp your most probable remaining amount would be 70 000$. On top of that you can make the estimate that since at the moment you're delivering with the cost of 1333$/sp the current worst case scenario is 93 333$ to go. Then you can also provide a happy case scenario in which you will speed things up and in the future per sp cost drops to eg. 750$ and your remaining cost would be 52 500$.

Given these costs you could make an estimate that you have 60% confidence on hitting the 70 000$ and maybe 15% for both ends of the budget (with some percentage for very bad or very good scenarios). Here's a picture:

5%        15%       60%       15%      5%

<52k      52 500    70 000    93 000   >93k

Whenever estimating speed, velocity, costs, etc. in the future, using "yesterday's weather" is a pretty good starting point. And also when you're giving estimates on something you should always aim for giving a range along with some probabilities.