handling schedules and budgets in an agile project

Handling Schedules and Budgets in an Agile Project

David P. Caccamo, M.Econ., PMP, PMI‐ACP, CSM

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

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…

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!”

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 

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

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

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

Scrum Framework

R1

R2

R3

Release Planning

Product Backlog

Sprint Backlog

Sprint2‐4wk

Potentially Shippable Product

Sprint Planning

Daily Scrum

Vision

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

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)

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

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

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

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?)

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

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

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.

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

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” )

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

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

Money Buffer

• 7 developer x 10% = approximately one (1) additional developer

1 developer x 20 weeks x $5,000 per week = $100,000

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)

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

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)

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

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