Agile and fixed budget projects

31
Agile and Fixed Budget Projects Learn through sharing From : Gul Mohammad

Transcript of Agile and fixed budget projects

Page 1: Agile and fixed budget projects

Agile and Fixed Budget ProjectsL e a r n t h r o u g h s h a r i n g

From : Gu l Mohammad

Page 2: Agile and fixed budget projects

The Big Picture

Page 3: Agile and fixed budget projects

Framework

Modularity: The process is broken down into various components.Iterative: Short cyclesTime-BoundAdaptive: React and adapt to change along with the new risks exposed during the cycle.IncrementalConvergent: Proactively attacking the risks, the system can therefore roll-out in increments.People-Oriented(Empowering the peoples): Stakeholders involved can help the organic evolution of the system.

Page 4: Agile and fixed budget projects

Manifesto

Page 5: Agile and fixed budget projects

Agile framework

Page 6: Agile and fixed budget projects

Agile Methods

• Scrum• Scrum ban• Adaptive Software Development (ASD)• Agile Modeling• Agile Unified Process (AUP)• Crystal Clear Methods (Crystal Clear)• Disciplined Agile Delivery• Dynamic Systems Development Method (DSDM)• Extreme Programming (XP)• Feature Driven Development (FDD)• Lean software development• Kanban (development)

Page 7: Agile and fixed budget projects

Advantages

• Helps mitigate changing requirements and priorities•  Lowers cost of change•  Encourages higher quality, simpler code•  Reduces risk and defects•  Maximizes return on investment (ROI)•  Provides visibility into project progress•  Delivers business value earlier and more frequently

Page 8: Agile and fixed budget projects

Disadvantages

• Needs consistent business involvement• Requires more discipline• May not be applicable all projects, all people and all situations, although it can be applied

in many situations• Does not replace solid software engineering practice – you need to be a solid software

engineer to be a solid agile software engineer

Page 9: Agile and fixed budget projects

Scrum….

Page 10: Agile and fixed budget projects

Scrum

It is an Agile project management method

Characteristics: Prioritized work is done. Completion of backlog items Progress is explained Agile Software Development

Page 11: Agile and fixed budget projects

Overview

Process• Sprint• Daily Scrum• Sprint review and retrospection

Roles• Product owner and product backlog

• Scrum Master• The Team• The Done• Good Engineering practices

Page 12: Agile and fixed budget projects

Values

• Commitment • Respect• Focus • Courage• Openness

Page 13: Agile and fixed budget projects

Flow

Page 14: Agile and fixed budget projects

Sprint planning meeting

Page 15: Agile and fixed budget projects

Backlog (list of stories)

The backlog in Scrum is a prioritized features list, containing short descriptions of all functionality desired in the product.

Page 16: Agile and fixed budget projects

Story!!!

Short and simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.

A typical template:As a <type of user>, I want <some goal> so that <some reason>.As a user, I can backup my entire hard drive.

A big user story is called epic and can be broken down into multiple small stories.

Page 17: Agile and fixed budget projects

Story Points

An arbitrary measures. This is used to measure the effort required to implement a story.A story point = Complexity + Uncertainty + Effort

Point Size : 1,2,4,8,16 or X Small, Small, Medium, Large, Extra Large. Mostly commonly used series is the Fibonacci series .

Page 18: Agile and fixed budget projects

Backlog

Page 19: Agile and fixed budget projects

Burn down chart

Page 20: Agile and fixed budget projects

Velocity

At the end of each iteration, the team adds up effort estimates associated with user stories that were completed during that iteration. This total is called velocity.

Page 21: Agile and fixed budget projects

Done

A typical conversation between developer and Product owner.

Product owner (PO): Is the software done? Developer (Dev): Yes, almost. PO: Can we go to production? Dev: No, not yet. PO: Why not? Dev: Well, some bugs have to be solved, some integration tests still have to be run, release packages have to updated, etc. PO: When can we go to production ? Dev: I don't know. . . .

PO: *******************************************To avoid this kind of situation there should be a solid definition of done.e.g. Done = Coded+tested+varified+integrated+Ready for Production

Page 22: Agile and fixed budget projects

Fixed budget projects

Page 23: Agile and fixed budget projects

A Note

Agile, by its very nature is inherently an open-ended time-and-material (T&M) type of contract which vendors love but clients are hesitant to sign up.Both the software developer and client organization want to know how much the project will cost, not to mention how long it will take.

Page 24: Agile and fixed budget projects

Solution

First, it’s important to determine whether you are trying to complete the entire large program as a fixed contract or a first (single) release-type project as a fixed contract.

(we choose later)

Since it will allow both the vendor and the client to learn about the project goals and important Agile principles such as sustainable velocity.

Page 25: Agile and fixed budget projects

Estimation

• Customer and Vendor finalizes the backlog and becomes to estimate velocity.

• Estimation can be done by comparing with previous stories or knowledge base or whatever technique you use.

• Ideal sprint size is 2 weeks.

• Prepare more than a week efforts. you will most likely still need to re-estimate based on the actual or sustainable velocity that comes into play after five to ten iterations.

• Form the ideal sprint in hours Developers=4 Daily work hours = 6.5 to 8 hours 5 days a week For 2 weeks sprint planning = 1 day and 1 day for retrospection; working days=8 Hours 182 to 224 a week. Man Hours. 28 to 40 Range of Ideal Sprint 246 to 314

Page 26: Agile and fixed budget projects

Estimation

Backlog stories 30Hours calculated 1000Points 500Sprint size weeks 2(1 day planning + 1 day retro) = 8 daysDevelopers 4Hours/Day (4*8) 32Sprint Hours 320Per Sprint points 160Total Sprints for release 3.125Agility + scope buffer 0.25Grand Total 3.38Release Days 33.75

A rough Estimated Release

Page 27: Agile and fixed budget projects

Calculating velocity

• Take the stories that have been broken into tasks• Take total estimated hours for all tasks. then we can select how many points can

we put into sprint• Now look at your entire backlog and count how many sprints you will need to complete all of the backlog.• By placing them into sprints based on the velocity and business value, you can

then understand where your natural releases are.

Note: please be wary that everything is based on rough estimation at this time

This would be a pilot release. Once you get through you, the client and your team will be much better on estimation for next release.

Page 28: Agile and fixed budget projects

Contract Agility buffer

At this point, the contract agility buffer comes into play. Normally we include some level of capacity buffer, typically 20% to 40%. plus some form of a scope buffer.

60/40/20 Rule:• Breaks the release backlog and project scope into a 60%, 40% and 20% prioritized list.• 60% is “must-have,” (Actual project target) • 40% is “would like to have,” (Negotiable: features can change and remove here) • 20% is considered a “stretch goal.” positive buffer

Page 29: Agile and fixed budget projects

Change Management

Now we have sense of time and size to be able to create a contract, with one outstanding issue: The change control management plan. In essence, there are three main components to consider:

1. A high level of trust to be developed between the client and vendor regarding change control.

2. The basis of the scope is the selected story. In case of change some level of change control is required. Once the new story has been fully defined and accepted, the client should then select an equally sized item from the original backlog to be removed and placed back into the program backlog instead of the release backlog. At that point, a zero-cost of change control is issued to change the fixed-scope portion of the contract.

3. The alternative is that the client wants to add an item to or change a completed item on the backlog without removing anythingfrom the release backlog. In this case, we would again fully develop the new story, and then once accepted, we would create acost-type change control based on the sizing. At a minimum, the cost would change scope, but it would potentially change priceand time, as well.

Page 30: Agile and fixed budget projects

Final Notes

Make sure the teams complete all of the 60% portion before beginning work on the 40% negotiable portion.

Cost overrunAgile controls the cost overrun with close interaction

AssumptionsTake special care of assumptions. Clear conversations during analysis and RFP process.Building clear expectation and honest communication.One major component to success fully transitioning to the Agile practice is to have a strong and trusting relationship.

Page 31: Agile and fixed budget projects

Thank You