Uncertainty in Agile Projects A lightning talk about uncertainty
Agile is a two way effort <ul><li>Even the best Agile team will have mountains of problems if the business is not engaged ...
Involve the business in your project <ul><li>Do what the customer wants and not what you (or the BA) think it’s best </li>...
What is uncertainty? <ul><li>The unforeseen which will affect negatively the team’s velocity  </li></ul><ul><li>If the tea...
Example - 1 <ul><li>Requirements always change . The team (including the customer) planned to build something but somethin...
Example – 2 <ul><li>Over optimism/pessimism . During planning  the team under/over-estimates the duration of a task. In bo...
Example – 3 <ul><li>Lack of know-how . The team doesn’t have the necessary knowledge (technical/business) to deliver, but ...
Example - 4 <ul><li>Defects/Non-iteration activities . Most customers think of perfect functionalities when planning. Have...
Uncertainty needs to be estimated <ul><li>Taking into account uncertainty helps you to deliver what was promised and will ...
Estimating uncertainty is…uncertain <ul><li>Estimation cannot be precise due to the same nature of uncertainty </li></ul><...
Estimate what can be mitigated <ul><li>There is no point in estimating uncertainty which cannot be mitigated (example: a m...
Uncertainty during planning <ul><li>Identify your project category </li></ul><ul><ul><li>Time Fixed </li></ul></ul><ul><ul...
Time Fixed <ul><li>The project needs to be delivered by a certain date. Often driven by marketing research.  The uncertain...
Functionality fixed <ul><li>The system cannot go live without a certain set of functionalities.  Uncertainty lies in the d...
If you cannot be precise…Be vague <ul><li>Time fixed.  We will deliver between 80 and 120 Story Points </li></ul><ul><li>F...
Let the business know you are estimating uncertainty <ul><li>Be vague about what/when the team is going to deliver.  </li>...
Uncertainty and Defects  - 1 <ul><li>Very controversial subject </li></ul><ul><li>My approach:  </li></ul><ul><ul><li>Cate...
Uncertainty and Defects – 2 <ul><li>80/20 or 70/30 rule.  </li></ul><ul><li>Time allocated to uncertainty is not wasted! <...
Working with dual velocity <ul><li>Catering for uncertainty during planning leads to a “dual velocity” model:  </li></ul><...
Estimating uncertainty pays back <ul><li>If unforeseen things actually don’t happen (e.g. there are no production bugs) st...
Upcoming SlideShare
Loading in …5
×

Uncertainty in agile projects

1,048 views
910 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,048
On SlideShare
0
From Embeds
0
Number of Embeds
96
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Uncertainty in agile projects

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

×