A presentation about how to apply Agile Methodology on Fixed Budget projects. Where time and cost are bot constraints.

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

2. The Big Picture

3. Framework
Modularity: The process is broken down into various components.
Iterative: Short cycles
Time-Bound
Adaptive: React and adapt to change along with the
new risks exposed during the cycle.
Incremental
Convergent: 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.

4. Manifesto

5. Agile framework

6. 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)

7. 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

8. 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

9. Scrum….

10. Scrum
It is an Agile project management method
Characteristics:
Prioritized work is done.
Completion of backlog items
Progress is explained
Agile Software Development

11. Overview
Process
• Sprint
• Daily Scrum
• Sprint review and retrospection
Roles
• Product owner and product backlog
• Scrum Master
• The Team
• The Done
• Good Engineering practices

12. Values
• Commitment • Respect
• Focus • Courage
• Openness

13. Flow

14. Sprint planning meeting

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

16. 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.

17. 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 .

18. Backlog

19. Burn down chart

20. 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.

21. 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

22. Fixed budget projects

23. 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.

24. 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.

25. 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

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

27. 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.

28. 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

29. 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 anything
from the release backlog. In this case, we would again fully develop the new story, and then once accepted, we would create a
cost-type change control based on the sizing. At a minimum, the cost would change scope, but it would potentially change price
and time, as well.

30. Final Notes
Make sure the teams complete all of the 60% portion before beginning work on the 40% negotiable portion.
Cost overrun
Agile controls the cost overrun with close interaction
Assumptions
Take 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.

31. Thank You