Khushboo SinghProject Manager| Envestnet|YodleeBangalore, Karnataka, India
I am trying to come up with budget estimation template. I used one of the templates from projectmanagement.com. For any project, list out the different tasks that would be needed, find roles/employees that would be engaged to complete the task; number of hours that they would consume and their hourly labor rate. At the end, add Buffer and reserve; this would give the budget.
Is this way applicable to Agile as well?
When I saw the Project Tasks, it was in waterfall model, how should we estimate in Agile?
How do we come up with Buffer and reserve percentage/numbers?
What should be the criteria for reserve? Saving Changes...
Sort By:
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Take a look to Michael Cohn´s "Agile Estimating and Planning" Saving Changes...
The book Sergio mentions is a good reference, but might be confusing if you are not familiar with Agile. There are a lot of sites and blogs with basic information on Scrum. Scrumalliance.org. Scrum.org. Mountaingoatsoftware.com. ...to name a few. Understand the basics, then read Michael Cohn's book.
You can't really apply waterfall approaches to agile estimation, largely because you won't have all of the work defined up front. Here is a simple narrative:
* Working with Stakeholders, a Product Owner develops a roadmap for a product or features on a product.
* The Product Owner and Stakeholders identify user personas and develop user stories based on the personas.
* The user stories are put into the product backlog and prioritized.
* The Product Owner and the Agile team review the top priority user stories; the team asks questions and sizes the work.
* The team fits as many of the top priority user stories as they can finish during one sprint and moves them to the sprint backlog. Work they do not finish or that is not accepted by the Product Owner at the end of the sprint goes back into the Product Backlog, and the cycle starts over again.
If a Product Backlog is small enough, it is possible to size all the stories before starting the first sprint. As projects get larger, you are more likely to only be able to estimate when the next feature(s) will be released, and not the finished product.
This description does not cover all possible scenarios; it's just an attempt at a short description. Saving Changes...
Community Champion
