Agile Development at a Fixed Cost: Project Acquisition

1. Agile Developmentat a Fixed Cost:Project Acquisition

2. Fixed Cost Agile Development: Project Acquisition

3. Introduction

4. What is fixed cost and why use it? What is fixed cost and why use it? The team needs to complete the same activities as in an agile process, but some activities (such as estimation and pricing) are front loaded.What is fixed cost and why use it? The team needs to complete the same activities as in an agile process, but some activities (such as estimation and pricing) are front loaded.

5. What Is Fixed Cost and Why Use It?

6. Fixed cost versus time and materials and subscription models

7. The risk premium

9. Assumes the customer has requested for a specific set of functionality to be developed

10. Activity front loading

11. Relies on agile processes

12. Ideal Days

13. Ideal Days - Definition An estimate of effort expressed in days, where one quarter day is the smallest increment. (An increment of .1 is used for reminders or tasks estimated at an hour or less.) Definition An estimate of effort expressed in days, where one quarter day is the smallest increment. (An increment of .1 is used for reminders or tasks estimated at an hour or less.)Definition An estimate of effort expressed in days, where one quarter day is the smallest increment. (An increment of .1 is used for reminders or tasks estimated at an hour or less.)

14. Ideal Days �Best defined by the question: "How long would it take me to complete this work if I were allowed to work without interruption until the work was complete, if I had access to the people and resources I needed when I needed then, and if there were the typical number of technical issues along the way but nothing went horribly wrong?" Best defined by the question "How long would it take me to complete this work if I were allowed to work without interruption until the work was complete, if I had access to the people and resources I needed when I needed then, and if there were the typical number of technical issues along the way but nothing went horribly wrong?"Best defined by the question "How long would it take me to complete this work if I were allowed to work without interruption until the work was complete, if I had access to the people and resources I needed when I needed then, and if there were the typical number of technical issues along the way but nothing went horribly wrong?"

15. Functional Stories

16. Functional / User Stories A Story represents a recognizable functional experience for the user. It typically, should not address technical details. For the purposes working within the customer's understanding, stories may be considered roughly analogous to features or use cases. They may also be though to as an aggregation of requirements that all speak to one user experience. Definition A User Story represents a recognizable functional experience for the user. It typically, should not address technical details. For the purposes working within the customer's understanding, stories may be considered roughly analogous to features or use cases. They may also be though to as an aggregation of requirements that all speak to one user experience.Definition A User Story represents a recognizable functional experience for the user. It typically, should not address technical details. For the purposes working within the customer's understanding, stories may be considered roughly analogous to features or use cases. They may also be though to as an aggregation of requirements that all speak to one user experience.

17. Techinical Tasks

18. Task - Definition The implementation-specific components into which a User Story is broken. May also relate to process, such as a task to obtain approval for a given design. Definition The implementation-specific components into which a User Story is broken. May also relate to process, such as a task to obtain approval for a given design.Definition The implementation-specific components into which a User Story is broken. May also relate to process, such as a task to obtain approval for a given design.

19. Estimation

20. Estimation

21. Where the major functional stories for a project are first identified and estimated. Where the major functional stories for a project are first identified and estimated. These stories should clearly state the project's value to the customer and should be used and tracked through the life of the project.Where the major functional stories for a project are first identified and estimated. These stories should clearly state the project's value to the customer and should be used and tracked through the life of the project.

22. Process Detail

23. Gather domain experts and one or more individuals who will actually perform the work Gather domain experts and one or more individuals who will actually perform the work You will get the best results by employing the most knowledgeable individuals. Someone else can still perform all other proposal and scheduling activities. This is essential for the vendor who may have to make good on the quoted price. It is also important for the in-house development team that has a reputation to build or maintain.Gather domain experts and one or more individuals who will actually perform the work You will get the best results by employing the most knowledgeable individuals. Someone else can still perform all other proposal and scheduling activities. This is essential for the vendor who may have to make good on the quoted price. It is also important for the in-house development team that has a reputation to build or maintain.

24. Determine how non-development work will be estimated Determine how non-development work will be estimated Requirements refinement, design, documentation, user-acceptance testing and deployment. Three possible approaches: 1. Bake it into the ideal days. Developers consider doing it as part of the rest of their work. 2. Bake it into the overhead. Developers do not consider this as part of the rest of their work. The work is then factored in as part of the planning process. 3. Estimate it out. This means separate stories such as Refine Requirements, Design Job Runner, Deploy through System Integration and User Acceptance Testing. Each story should still be associated with some sort of deliverable that concretely moves the project forward.Determine how non-development work will be estimated Requirements refinement, design, documentation, user-acceptance testing and deployment. Three possible approaches: 1. Bake it into the ideal days. Developers consider doing it as part of the rest of their work. 2. Bake it into the overhead. Developers do not consider this as part of the rest of their work. The work is then factored in as part of the planning process. 3. Estimate it out. This means separate stories such as Refine Requirements, Design Job Runner, Deploy through System Integration and User Acceptance Testing. Each story should still be associated with some sort of deliverable that concretely moves the project forward.

25. Segment all work into functional categories Segment all work into functional categories User stories are ideal for this. It is important to speak the customer's language, so use cases, a feature list or some other customer-supplied requirements breakdown may do. Categorize and estimate everything.Segment all work into functional categories User stories are ideal for this. It is important to speak the customer's language, so use cases, a feature list or some other customer-supplied requirements breakdown may do. Categorize and estimate everything.

26. Initial pass Initial pass Estimate each story in Ideal Days, but do not estimate in increments smaller than three ideal days. The goal is to stop staring at a clean sheet of paper.Initial pass Estimate each story in Ideal Days, but do not estimate in increments smaller than three ideal days. The goal is to stop staring at a clean sheet of paper.

27. Consecutive passes Consecutive passes Refine the previous pass. If a story needs to be refined to produce an accurate estimate, break it into tasks. Continue until the experts are either satisfied or out of time.Consecutive passes Refine the previous pass. If a story needs to be refined to produce an accurate estimate, break it into tasks. Continue until the experts are either satisfied or out of time.

28. Trap Stories and Tasks: They feed right into Planning, Pricing and Execution Trap Stories and Tasks: They feed right into Planning, Pricing and Execution This information will feed into planning, pricing, execution and evaluation. This is when teams should seriously consider using a task management database instead of MS Project or index cards.Trap Stories and Tasks: They feed right into Planning, Pricing and Execution This information will feed into planning, pricing, execution and evaluation. This is when teams should seriously consider using a task management database instead of MS Project or index cards.

29. Planning

30. Planning

31. This section assumes the customer wants to know when the project will be complete and what is the work schedule

32. Process Detail

33. Review list of estimated stories to ensure all activities are covered

34. Convert ideal days into project weeks

36. Determine how many releases the team can do

37. Draw up Agile WBS (if necessary)

40. Trap Planning Data: It will feed into pricing and execution

41. Pricing

42. Pricing

43. A fixed price can be calculated regardless of whether a planning process was performed

44. Process Detail

45. Review stories and plan to ensure all activities are covered

46. Account for non-development players

47. Calculate Price

50. Fixed Cost Agile Development: Project Acquisition

51. Comprehensive Technology & Management ConsultingYour Complex Challenges. Our Innovative Solutions. 200 Lincoln Street, Suite 400Boston, Massachusetts 02111tel: 617.357.5233 fax: 617. 357.5234www.quoininc.com