![Page 1: Handling Schedules and Budgets in an Agile Project](https://reader031.vdocuments.us/reader031/viewer/2022020916/61a779cf57b6fd2e35456af6/html5/thumbnails/1.jpg)
Handling Schedules and Budgets in an Agile Project
David P. Caccamo, M.Econ., PMP, PMI‐ACP, CSM
![Page 2: Handling Schedules and Budgets in an Agile Project](https://reader031.vdocuments.us/reader031/viewer/2022020916/61a779cf57b6fd2e35456af6/html5/thumbnails/2.jpg)
Agile Manifesto
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
• Individuals and Interactions over Processes and Tools• Working Software over Comprehensive Documentation• Customer Collaboration over Contract Negotiation• Responding to Change over Following a Plan
![Page 3: Handling Schedules and Budgets in an Agile Project](https://reader031.vdocuments.us/reader031/viewer/2022020916/61a779cf57b6fd2e35456af6/html5/thumbnails/3.jpg)
The Agile Manifesto’s Final Line
“That is, while there is value in the items on the right, we value the items on the left more.”
Unfortunately, not everyone sees it that way…
![Page 4: Handling Schedules and Budgets in an Agile Project](https://reader031.vdocuments.us/reader031/viewer/2022020916/61a779cf57b6fd2e35456af6/html5/thumbnails/4.jpg)
Common Complaints from Management
• “You want me to sign off on a project but you can’t tell me how long it is going to take or how much it is going to cost!”
• “You don’t have any artifacts that allow me to know whether you are doing a good job – OR NOT!”
![Page 5: Handling Schedules and Budgets in an Agile Project](https://reader031.vdocuments.us/reader031/viewer/2022020916/61a779cf57b6fd2e35456af6/html5/thumbnails/5.jpg)
Possible?
• To provide a level of documentation and reports that is both reasonable from an Agile perspective while still giving managers information they need
• To support a level of long‐run planning that fits with the needs of the accountants and budget analysts
![Page 6: Handling Schedules and Budgets in an Agile Project](https://reader031.vdocuments.us/reader031/viewer/2022020916/61a779cf57b6fd2e35456af6/html5/thumbnails/6.jpg)
Levels of Agile Planning
• Level I– Vision, Mission, Success Criteria
• Level II– Product Roadmap (6‐9 months, or longer)
• Level III– Release Plan
• Level IV– Iteration Plan
• Level V – Daily Standup Meeting
![Page 7: Handling Schedules and Budgets in an Agile Project](https://reader031.vdocuments.us/reader031/viewer/2022020916/61a779cf57b6fd2e35456af6/html5/thumbnails/7.jpg)
Scrum Framework
R1
R2
R3
Release Planning
Product Backlog
Sprint Backlog
Sprint2‐4wk
Potentially Shippable Product
Sprint Planning
Daily Scrum
Vision
Level I
Level II
Level III Level IV
Level V
![Page 8: Handling Schedules and Budgets in an Agile Project](https://reader031.vdocuments.us/reader031/viewer/2022020916/61a779cf57b6fd2e35456af6/html5/thumbnails/8.jpg)
Levels of Agile Planning
• Level I– Vision, Mission, Success Criteria
• Level II– Product Roadmap (6‐9 months, or longer)
• Level III– Release Plan
• Level IV– Iteration Plan
• Level V – Daily Standup Meeting
![Page 9: Handling Schedules and Budgets in an Agile Project](https://reader031.vdocuments.us/reader031/viewer/2022020916/61a779cf57b6fd2e35456af6/html5/thumbnails/9.jpg)
Scrum Framework
R1
R2
R3
Release Planning
Product Backlog
Sprint Backlog
Sprint2‐4wk
Potentially Shippable Product
Sprint Planning
Daily Scrum
Vision
![Page 10: Handling Schedules and Budgets in an Agile Project](https://reader031.vdocuments.us/reader031/viewer/2022020916/61a779cf57b6fd2e35456af6/html5/thumbnails/10.jpg)
Level III – Release Planning Overview
• Develop a set of requirements in the form of User Stories
• Should represent the themes of the Roadmap• Product Owner selects features (User Stories) to be included in next release– Done in concert with the ScrumMaster and Team members
– Becomes the Product Backlog
![Page 11: Handling Schedules and Budgets in an Agile Project](https://reader031.vdocuments.us/reader031/viewer/2022020916/61a779cf57b6fd2e35456af6/html5/thumbnails/11.jpg)
What is the Product Backlog?
• The set of user stories identified by the Product Owner for the next release
• These stories are:– Prioritized (by business value)– Estimated (using relative estimating techniques)– In some cases, actually “Epics” (large stories requiring decomposition)
![Page 12: Handling Schedules and Budgets in an Agile Project](https://reader031.vdocuments.us/reader031/viewer/2022020916/61a779cf57b6fd2e35456af6/html5/thumbnails/12.jpg)
What is Required?
• A team with enough experience at estimating to provide reliable relative estimates for the User Stories
• A team with enough experience at executing to have developed a reliable velocity
• A product owner to set the priorities for the user stories
![Page 13: Handling Schedules and Budgets in an Agile Project](https://reader031.vdocuments.us/reader031/viewer/2022020916/61a779cf57b6fd2e35456af6/html5/thumbnails/13.jpg)
Step One – Determine the Minimal Marketable Features (MMF)
• Product Owner’s responsibility• MMF represents the subset of features that can:– Be completed quickly– Be sent to market– Provide a vehicle for customer feedback
![Page 14: Handling Schedules and Budgets in an Agile Project](https://reader031.vdocuments.us/reader031/viewer/2022020916/61a779cf57b6fd2e35456af6/html5/thumbnails/14.jpg)
Considerations
• What is the minimal set of features which, if completed, would constitute a successful project?– The stories associated with these features are marked as top priority
– e.g., if using MoSCoW, these are all “M” stories –Must Haves
![Page 15: Handling Schedules and Budgets in an Agile Project](https://reader031.vdocuments.us/reader031/viewer/2022020916/61a779cf57b6fd2e35456af6/html5/thumbnails/15.jpg)
Step Two – Determine the MMF Point Value
• Points are estimated using relative estimating– Perhaps using planning poker– Done by the team (who better to estimate how long something should take?)
![Page 16: Handling Schedules and Budgets in an Agile Project](https://reader031.vdocuments.us/reader031/viewer/2022020916/61a779cf57b6fd2e35456af6/html5/thumbnails/16.jpg)
Step 3 – Make the MMF Points 70% of the Project
• The “Must Haves” should represent 70% of the user story point value of work for the project– The remaining 30% of the user stories are designated “S” – “Should Haves”
• The “S” stories represent the buffer (or safety factor for the project) – If the “M” stories take longer, drop “S” stories
![Page 17: Handling Schedules and Budgets in an Agile Project](https://reader031.vdocuments.us/reader031/viewer/2022020916/61a779cf57b6fd2e35456af6/html5/thumbnails/17.jpg)
Step 4 – Divide the Total Project Points by the Velocity
• Determines the number of Sprints required to do the required work, including the safety buffer– Product Owner can do the “Should Haves” if time is available, or
– Could finish the project early
• Don’t forget Sprint 0
![Page 18: Handling Schedules and Budgets in an Agile Project](https://reader031.vdocuments.us/reader031/viewer/2022020916/61a779cf57b6fd2e35456af6/html5/thumbnails/18.jpg)
Example
• The Product Owner identifies 20 User Stories as essential for project success
• These 20 stories represent 154 points of work
154 points = 220 points total work.70
• 220 total points – 154 “M” pts. = 66 “S” pts.
![Page 19: Handling Schedules and Budgets in an Agile Project](https://reader031.vdocuments.us/reader031/viewer/2022020916/61a779cf57b6fd2e35456af6/html5/thumbnails/19.jpg)
Example (continued)
• With a given velocity of 22 pts. per Sprint220 pts / 22 pts. per Sprint = 10 Sprints10 Sprints * 2 weeks per Sprint = 20 weeks
• 20 weeks of work + 1 Sprint 0 week
= 21 weeks
![Page 20: Handling Schedules and Budgets in an Agile Project](https://reader031.vdocuments.us/reader031/viewer/2022020916/61a779cf57b6fd2e35456af6/html5/thumbnails/20.jpg)
Cost
• As with time, the costing assumption of Agile is that costs are best estimated by the individuals who are going to do the job – the developers
• Use time‐boxing methods– Number of Sprints has been estimated– Resources per Sprint are known (or at least “plan‐able” )
![Page 21: Handling Schedules and Budgets in an Agile Project](https://reader031.vdocuments.us/reader031/viewer/2022020916/61a779cf57b6fd2e35456af6/html5/thumbnails/21.jpg)
Example
• We have 20 weeks of work • 7 team members will be utilized• The cost of a team member is $5,000 per week
7 x $5,000 = $35,00020 weeks x $35,000 = $700,000Plus whatever the Sprint 0 costs, e.g., $10,000Total Budget = $710,000
![Page 22: Handling Schedules and Budgets in an Agile Project](https://reader031.vdocuments.us/reader031/viewer/2022020916/61a779cf57b6fd2e35456af6/html5/thumbnails/22.jpg)
Alternate Method of Adding Buffer
• This method would use the MMF divided by the velocity to get the length of the project calculated in Sprints– From our example, 7 sprints or 14 weeks + 1
• Safety factor is in the form of money– 10% additional developers added to project– Their cost is the safety factor
![Page 23: Handling Schedules and Budgets in an Agile Project](https://reader031.vdocuments.us/reader031/viewer/2022020916/61a779cf57b6fd2e35456af6/html5/thumbnails/23.jpg)
Money Buffer
• 7 developer x 10% = approximately one (1) additional developer
1 developer x 20 weeks x $5,000 per week = $100,000
![Page 24: Handling Schedules and Budgets in an Agile Project](https://reader031.vdocuments.us/reader031/viewer/2022020916/61a779cf57b6fd2e35456af6/html5/thumbnails/24.jpg)
Budget and Schedule
• The project estimates are (from our examples):– 21 weeks at $710,000 (with a safety factor built into the schedule)
Or– 15 weeks at $810,000 (with a safety factor built into the budget)
![Page 25: Handling Schedules and Budgets in an Agile Project](https://reader031.vdocuments.us/reader031/viewer/2022020916/61a779cf57b6fd2e35456af6/html5/thumbnails/25.jpg)
Release Metrics
• Release Burndown Chart– Shows the number of story points that remain in the Product Backlog
– Provides an indication of how much more work remains to be done
![Page 26: Handling Schedules and Budgets in an Agile Project](https://reader031.vdocuments.us/reader031/viewer/2022020916/61a779cf57b6fd2e35456af6/html5/thumbnails/26.jpg)
Release Metrics
• Release Burnup Chart– Illustrates the number of story points completed during the release
– Indicates total number of story points in the Product Backlog (shows when there are increases)
![Page 27: Handling Schedules and Budgets in an Agile Project](https://reader031.vdocuments.us/reader031/viewer/2022020916/61a779cf57b6fd2e35456af6/html5/thumbnails/27.jpg)
Final Thought: Agile Planning Assumes…
• That you have a self‐directed group of motivated individuals who have worked together as a team and thus have:– Demonstrated good planning skills– Effective working relationships
![Page 28: Handling Schedules and Budgets in an Agile Project](https://reader031.vdocuments.us/reader031/viewer/2022020916/61a779cf57b6fd2e35456af6/html5/thumbnails/28.jpg)
Breaking up the Team …
• Lowers the team’s ability to reliably estimate project elements
• Harms the relationships between the members and thus affects the efficiency level that the planning was based upon