Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, Cost Management, Scrum
Budgeting and cost tracking for a Scrum project
Network:47



Hi,

Just curious to know how you budget and track costs for a Scrum project? I haven't done any cost tracking, hence wanted to learn/understand how it is done.

thanks
Robert.
Sort By:
Page: 1 2 next>
Network:1375



Aside from capital costs, you can look at capacity or velocity driven tracking. Below is a link to an article for a velocity based approach. Disclaimer, I have not put this into practice - yet ....

http://www.agileadvice.com/2011/02/04/agil...six-easy-steps/

Capacity planning - looking at number of resources, the amount of actual work hours expected in the day (8hrs - lunch time - meeting time = daily capacity * # team members * 20 days (month sprint) = sprint capacity
...
2 replies by Andrew Craig and Robert Poddar
Oct 06, 2017 7:08 AM
Robert Poddar
...
Hi Andrew,

Thanks for your the link, will defenitely go through it. Just to understand that upfront (while budgeting), how does the team indicate the number of Sprints that it needs to complete all the features and provide the deliverables as per the scope document?

thanks
Robert.
Oct 06, 2017 11:56 AM
Andrew Craig
...
Absolutely. I'm going through a bit of transition myself, so I'm learning as well.

Based on the stories produced by the PO, and in review with the Development team, there should be a rough idea of the length of time - 3, 6, 12, sprints/months ...

With that in mind, elaborating the budget now with a capacity-driven template over that period. As the project progresses, the 'estimates' can be fine-tuned.
Network:47



Oct 06, 2017 6:19 AM
Replying to Andrew Craig
...
Aside from capital costs, you can look at capacity or velocity driven tracking. Below is a link to an article for a velocity based approach. Disclaimer, I have not put this into practice - yet ....

http://www.agileadvice.com/2011/02/04/agil...six-easy-steps/

Capacity planning - looking at number of resources, the amount of actual work hours expected in the day (8hrs - lunch time - meeting time = daily capacity * # team members * 20 days (month sprint) = sprint capacity
Hi Andrew,

Thanks for your the link, will defenitely go through it. Just to understand that upfront (while budgeting), how does the team indicate the number of Sprints that it needs to complete all the features and provide the deliverables as per the scope document?

thanks
Robert.
...
2 replies by Ashok Vasa and Stéphane Parent
Oct 06, 2017 7:32 AM
Stéphane Parent
...
I would think, Robert, that you have to estimate, at a high level. all the features going into the product backlog. Then it's just a question of dividing the estimate by the sprint duration to get the number of sprints.
Oct 14, 2017 5:06 PM
Ashok Vasa
...
Hi Robert,

This is a common concern.

To my knowledge, no one has yet come up with a reliable way to estimate the number of sprints based on a scope document alone.

This is because software development is difficult to estimate - it is like making a weather forecast. But yet, we do it all the time because it is easier to sell a project with estimates than to actually admit to that a customer we don’t know for sure.

Over the years, people have come up with many different ways to estimate software development - but none of them have proven to be accurate.
https://en.wikipedia.org/wiki/Software_dev...fort_estimation

Most teams are over-optimistic in their estimates. Here is some recommended reading on why software estimation is hard to do:
https://rclayton.silvrback.com/software-es...s-a-losing-game

As for the budget - unless it’s a research project, customers usually already have some idea of their budget and time limit. So instead it is better for the team to truly understand the customers most important problems and then work with them to find a solution, within their budget and time limit.

It is better to find most of the solution upfront before the team begins too much code. Some use paper prototypes, mock-ups, models, wireframes, etc. But again there is no magic approach. You have to find the one that works best for your situation.

The key message:
There is no magic solution. Ask probing questions of any one who claims to have a method that can accurately estimate the cost and time of software development. Question, and think critically before adopting any particular methodology - read, learn and test it for yourself and find what works for you.
Network:72623



Oct 06, 2017 7:08 AM
Replying to Robert Poddar
...
Hi Andrew,

Thanks for your the link, will defenitely go through it. Just to understand that upfront (while budgeting), how does the team indicate the number of Sprints that it needs to complete all the features and provide the deliverables as per the scope document?

thanks
Robert.
I would think, Robert, that you have to estimate, at a high level. all the features going into the product backlog. Then it's just a question of dividing the estimate by the sprint duration to get the number of sprints.
Network:296



Robert -

To add to the feedback provided by Stéphane and Andrew, there are two approaches for budgeting your variable costs on a project following Scrum or some other agile delivery methodology.

1. If the team is fairly comfortable with their top-down/analogous estimate, then you can fix costs up front and let scope be your variable. The assumption is that you can achieve an MVP (not an Eric Ries MVP, but rather a true marketable product) within that budget. Then, you would track your costs as on a normal project based on actual spend sprint over sprint.

2. Once features have been broken down at least to an epic level, the team would size the backlog and then apply an assumed (or actual if it's a long lived team working on the same product) velocity against that to figure out the number of sprints. Then if your labor and other variable costs are fixed per sprint, you just multiply the number of sprints by your per sprint costs. Then sprint over sprint as the backlog is refined & reduced and velocity increases and then stabilizes, the team will reforecast how many sprints are left to get to done.

Kiron
...
1 reply by Robert Poddar
Oct 13, 2017 6:43 AM
Robert Poddar
...
Hi Kiron,

Thanks for your inputs. I got the idea, on how to budget and track costs.. Initially i was very skeptical (since we don't practise) on should we budget and track costs, since at the Sprint Planning phase, the team will be able to indicate the tickets which they will work as well size them. I wasn't looking at overall picture, wherein how many Sprints would the team need to make a MSP (miminum shippable product).
Your Point 2, is a great way of doing it..

thanks once again for your input.. i have learnt something new.. :)
Network:1368



This is one (or perhaps the best) work I read about all related to cost inside agile environments: https://www.linkedin.com/pulse/agile-evm-f...cm-ncma-fellow.
...
1 reply by Robert Poddar
Oct 13, 2017 6:46 AM
Robert Poddar
...
Hi Sergio,

Thanks, i will defenitely go through the link that you shared.. thanks a lot :)

Robert.
Network:1375



Oct 06, 2017 6:19 AM
Replying to Andrew Craig
...
Aside from capital costs, you can look at capacity or velocity driven tracking. Below is a link to an article for a velocity based approach. Disclaimer, I have not put this into practice - yet ....

http://www.agileadvice.com/2011/02/04/agil...six-easy-steps/

Capacity planning - looking at number of resources, the amount of actual work hours expected in the day (8hrs - lunch time - meeting time = daily capacity * # team members * 20 days (month sprint) = sprint capacity
Absolutely. I'm going through a bit of transition myself, so I'm learning as well.

Based on the stories produced by the PO, and in review with the Development team, there should be a rough idea of the length of time - 3, 6, 12, sprints/months ...

With that in mind, elaborating the budget now with a capacity-driven template over that period. As the project progresses, the 'estimates' can be fine-tuned.
...
1 reply by Robert Poddar
Oct 13, 2017 6:45 AM
Robert Poddar
...
Hi Andrew,

Thanks for the link, i will defenitely go through it. By having the inputs from all of you, i am able to fairly understand, how one should track resource cost in an Agile project.
Network:47



Oct 06, 2017 9:06 AM
Replying to Kiron Bondale
...
Robert -

To add to the feedback provided by Stéphane and Andrew, there are two approaches for budgeting your variable costs on a project following Scrum or some other agile delivery methodology.

1. If the team is fairly comfortable with their top-down/analogous estimate, then you can fix costs up front and let scope be your variable. The assumption is that you can achieve an MVP (not an Eric Ries MVP, but rather a true marketable product) within that budget. Then, you would track your costs as on a normal project based on actual spend sprint over sprint.

2. Once features have been broken down at least to an epic level, the team would size the backlog and then apply an assumed (or actual if it's a long lived team working on the same product) velocity against that to figure out the number of sprints. Then if your labor and other variable costs are fixed per sprint, you just multiply the number of sprints by your per sprint costs. Then sprint over sprint as the backlog is refined & reduced and velocity increases and then stabilizes, the team will reforecast how many sprints are left to get to done.

Kiron
Hi Kiron,

Thanks for your inputs. I got the idea, on how to budget and track costs.. Initially i was very skeptical (since we don't practise) on should we budget and track costs, since at the Sprint Planning phase, the team will be able to indicate the tickets which they will work as well size them. I wasn't looking at overall picture, wherein how many Sprints would the team need to make a MSP (miminum shippable product).
Your Point 2, is a great way of doing it..

thanks once again for your input.. i have learnt something new.. :)
Network:47



Oct 06, 2017 11:56 AM
Replying to Andrew Craig
...
Absolutely. I'm going through a bit of transition myself, so I'm learning as well.

Based on the stories produced by the PO, and in review with the Development team, there should be a rough idea of the length of time - 3, 6, 12, sprints/months ...

With that in mind, elaborating the budget now with a capacity-driven template over that period. As the project progresses, the 'estimates' can be fine-tuned.
Hi Andrew,

Thanks for the link, i will defenitely go through it. By having the inputs from all of you, i am able to fairly understand, how one should track resource cost in an Agile project.
Network:47



Oct 06, 2017 10:36 AM
Replying to Sergio Luis Conte
...
This is one (or perhaps the best) work I read about all related to cost inside agile environments: https://www.linkedin.com/pulse/agile-evm-f...cm-ncma-fellow.
Hi Sergio,

Thanks, i will defenitely go through the link that you shared.. thanks a lot :)

Robert.
Network:23


Oct 06, 2017 7:08 AM
Replying to Robert Poddar
...
Hi Andrew,

Thanks for your the link, will defenitely go through it. Just to understand that upfront (while budgeting), how does the team indicate the number of Sprints that it needs to complete all the features and provide the deliverables as per the scope document?

thanks
Robert.
Hi Robert,

This is a common concern.

To my knowledge, no one has yet come up with a reliable way to estimate the number of sprints based on a scope document alone.

This is because software development is difficult to estimate - it is like making a weather forecast. But yet, we do it all the time because it is easier to sell a project with estimates than to actually admit to that a customer we don’t know for sure.

Over the years, people have come up with many different ways to estimate software development - but none of them have proven to be accurate.
https://en.wikipedia.org/wiki/Software_dev...fort_estimation

Most teams are over-optimistic in their estimates. Here is some recommended reading on why software estimation is hard to do:
https://rclayton.silvrback.com/software-es...s-a-losing-game

As for the budget - unless it’s a research project, customers usually already have some idea of their budget and time limit. So instead it is better for the team to truly understand the customers most important problems and then work with them to find a solution, within their budget and time limit.

It is better to find most of the solution upfront before the team begins too much code. Some use paper prototypes, mock-ups, models, wireframes, etc. But again there is no magic approach. You have to find the one that works best for your situation.

The key message:
There is no magic solution. Ask probing questions of any one who claims to have a method that can accurately estimate the cost and time of software development. Question, and think critically before adopting any particular methodology - read, learn and test it for yourself and find what works for you.
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"Always carry a flagon of whiskey in case of snakebite and furthermore always carry a small snake."

- W. C. Fields

ADVERTISEMENT

Sponsors