Uncertainty in agile projects
1 like782 views
This document discusses the importance of accounting for uncertainty in agile projects. It provides examples of sources of uncertainty like changing requirements, over or under estimation of tasks, and lack of technical knowledge. It recommends involving customers throughout the project, estimating uncertainty without being precise, and allocating time and resources to address defects and non-iteration work as a way to mitigate uncertainty. Estimating uncertainty helps deliver promised functionality on time and builds customer trust.
Uncertainty in agile projects
- 1. Uncertainty in Agile Projects A lightning talk about uncertainty
- 2. Agile is a two way effort Even the best Agile team will have mountains of problems if the business is not engaged
- 3. Involve the business in your project Do what the customer wants and not what you (or the BA) think it’s best Involve the customer in all phases of the project including planning, testing and risk sharing An engaged customer will understand uncertainty!
- 4. What is uncertainty? The unforeseen which will affect negatively the team’s velocity If the team can’t see it, it will eventually backfire
- 5. Example - 1 Requirements always change . The team (including the customer) planned to build something but something else was actually required
- 6. Example – 2 Over optimism/pessimism . During planning the team under/over-estimates the duration of a task. In both cases velocity (and the team’s reputation) will suffer
- 7. Example – 3 Lack of know-how . The team doesn’t have the necessary knowledge (technical/business) to deliver, but the management thought they did
- 8. Example - 4 Defects/Non-iteration activities . Most customers think of perfect functionalities when planning. Have you ever known a project without bugs or interruptions? The classic myth: my system is (bug free)
- 9. Uncertainty needs to be estimated Taking into account uncertainty helps you to deliver what was promised and will win you the customer’s trust. Let your customer know that you are factoring out some time to cater for uncertainty
- 10. Estimating uncertainty is…uncertain Estimation cannot be precise due to the same nature of uncertainty Estimation is a guess (more or less precise)
- 11. Estimate what can be mitigated There is no point in estimating uncertainty which cannot be mitigated (example: a missile taking out of action your entire plant). Areas which benefit the most from uncertainty estimation: planning and maintenance
- 12. Uncertainty during planning Identify your project category Time Fixed Functionality fixed
- 13. Time Fixed The project needs to be delivered by a certain date. Often driven by marketing research. The uncertainty lies in the amount of functionality the team will deliver
- 14. Functionality fixed The system cannot go live without a certain set of functionalities. Uncertainty lies in the delivery date
- 15. If you cannot be precise…Be vague Time fixed. We will deliver between 80 and 120 Story Points Functionality fixed. We will deliver sometime between November and January
- 16. Let the business know you are estimating uncertainty Be vague about what/when the team is going to deliver. Make sure your customer knows that for you not to have a crystal ball is good for the project
- 17. Uncertainty and Defects - 1 Very controversial subject My approach: Cater for defects during planning. Include all (unforeseen) non-iteration stuff under the umbrella defects and allocate some time for it! Dedicate (on a rota) one or more people to deal with defects. It’s not pleasant but it must be done
- 18. Uncertainty and Defects – 2 80/20 or 70/30 rule. Time allocated to uncertainty is not wasted!
- 19. Working with dual velocity Catering for uncertainty during planning leads to a “dual velocity” model: The velocity the team sees . The velocity the management sees . This is the result of applying 80% (or 70%) of your potential velocity to the project This is not about trust . The team should be pushed to produce the maximum whenever possible and the management should be given realistic figures
- 20. Estimating uncertainty pays back If unforeseen things actually don’t happen (e.g. there are no production bugs) staff dedicated to uncertainty can actually contribute to the team’s velocity Maintenance costs will be lower because maintenance starts when the a functionality gets deployed to production Customers will trust you more, because your deliveries become more accurate