A quick trip to the future land of no estimates
•
20 likes•8,891 views
Why do we estimate? What are the benefits we want to obtain with that practice? In this talk we'll explore the nature of estimates and offer an alternative: #NoEstimates. We'll look at some examples of how we can predict a release date of a project without any estimates, only relying on easily available data. Finally, we'll see how we can follow progress on a project at all times without having to rely on guesswork, and we will review how large, very large as well as small projects have already benefited from this in the past. At the end of the session you will be ready to start your own #NoEstimates journey, the next step in the #Agile journey.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (16)
Similar to A quick trip to the future land of no estimates
Similar to A quick trip to the future land of no estimates (20)
More from Vasco Duarte
More from Vasco Duarte (19)
Recently uploaded
Recently uploaded (20)
A quick trip to the future land of no estimates
- 1. A quick trip to the future Vasco Duarte @duarte_vasco
- 2. #NoEstimates: how you can predict the release date of your project without estimating
- 3. I am proud to be part of this community!
- 5. Kent Beck – Extreme Programming
- 6. Ken Schwaber - Scrum
- 7. Taiichi Ohno – Toyota Production System
- 8. Edwards W. Deming – Everything above...
- 9. “If I have seen further it is by standing on the shoulders of giants” - Isaac Newton
- 16. Customer Collaboration over Contract Negotiation Responding to Change over Following a Plan
- 21. 1.Select the most important piece of work you need to do 2.Break that work down into risk- neutral chunks of work 3.Develop each piece of work 4.Iterate and refactor #NoEstimates How-to
- 22. Is the system of development stable? (ref: SPC)
- 23. I AM GOING TO GO AHEAD AND ASK YOU TO DELIVER 10 STORIES NEXT SPRINT...
- 24. 0 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 velocity Average= LCL UCL Target Actual, measured throughput over 21 sprints
- 25. WTF!!!!! !#%&!
- 26. Can we use the data we observe to predict the system throughput and detect changes that affect system stability?
- 27. 1.Velocity outside limits 3 times in a row (“outside limits”) 2.There are 5 or more points in sequence (“run test”) System stability rules
- 28. 0 2 4 6 8 10 12 1 3 5 7 9 11 13 15 17 19 21 # of items/stories delivered LCL UCL average Team: AT 0 2 4 6 8 10 12 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 LCL UCL average # of items/stories delivered Team: RF 0 2 4 6 8 10 12 14 16 18 20 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 LCL UCL average # of items/stories delivered Team: RF2 0 5 10 15 20 25 1 3 5 7 9 11 13 15 17 19 21 # of items/stories delivered LCL UCL average Team: SH
- 29. -1 1 3 5 7 9 11 13 15 17 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 LCL UCL average # of items/stories delivered Team: K 0 2 4 6 8 10 12 14 16 1 2 3 4 5 6 7 8 # of items/stories delivered LCL UCL average Team: MPC 0 2 4 6 8 10 12 14 16 1 2 3 4 5 6 7 8 9 1011121314151617181920 # of items/stories delivered LCL UCL average Team: AS 0 5 10 15 20 25 30 1 2 3 4 5 6 7 8 9 10 # of items/stories delivered LCL UCL average Team: FC
- 31. Counting Stories vs. Estimated Story Points Q: Which ”metric” is more accurate when compared to what actually happened in the project?
- 33. Which metric predicted most accurately the output of the whole project? a) After only the first 3 Sprints b) After only the first 5 Sprints
- 34. Disclaimer... This is only one project! Find 21 more at: http://bit.ly/NoEstimatesProjectsDB
- 35. After just 3 sprints # of Stories predictive powerStory Points predictive power The true output: 349,5 SPs completed The predicted output: 418 SPs completed +20% The true output: 228 Stories The predicted output: 220 Stories -4%!
- 36. After just 5 sprints # of Stories predictive powerStory Points predictive power The true output: 349,5 SPs completed The predicted output: 396 SPs completed +13% The true output: 228 Stories The predicted output: 220 Stories -4%!
- 37. Q: Which ”metric” is more accurate when compared to what actually happened in the project?
- 38. 80% Late or Failed Source: Software Estimation by Steve McConnell
- 39. The larger the project, the bigger the problem Source: Software Estimation by Steve McConnell
- 40. Source: Software Estimation by Steve McConnell
- 41. #ofprojects More lateEarly Likelihood of pa projecty being on time On Time
- 42. Comparison of 17 projects ending between 2001 and 2003. (Average: 62%)
- 44. Take #NoEstimates and experiment! Learn, Be Agile!
- 45. Click here! Sign-up and get the paper today! Sign-up and receive this paper which explains why we need #NoEstimates and how to get started! Includes: • Why estimates should not be used, and how they fail • An example of how #NoEstimates can reach a 4% accuracy to actuals • How to apply #NoEstimates: Vasco’s recipe!
Editor's Notes
- I am proud to be part of this community, the Agile community.
- We’ve been fighting accepted truths in the field of software development for many, many years.
- We’ve been fighting accepted truths in the field of software development for many, many years.
- Many of you are probably not old enough to remember the time when having a very long requirements phase was a must, and when non-incremental software development was the norm. First we had the phased waterfall, then we had to fight the idea that testing was something we did at the end of the project. Paper was where software was developed, do you remember that? Flow-diagrams, UML, etc.
- Coding was considered a “lowly” profession, only for juniors. The real software developers used paper, and the cool boys were all over Rational Rose! Code generation was the keyword! This is a photo of an actual code-monkey (just pay them with bananas), but you don’t see many actual code monkeys out there. In fact, a little know fact is: most software developers are human as of today! (I just saw the latest statistics) But many people still look (even 20 years later) at developers as code monkeys.
- Again, an old dictum. The Agile practitioners were called undisciplined, chaotic, lazy, idealists. You name it! For many Agile was untouchable, Agile was chaos.
- It took our community many years to get Agile accepted as a “serious” way to develop software. And as we can see from this email screen-shot. It now *really* is main-stream, when even the old-farts at PMI think it is worth their attention (no doubt because they want some of that certification money groovy train)
- Today, I stand in front of you as an advocate of the #NoEstimates approach to software development. #NoEstimates is just a minor Family in the Agile Species of software development approaches.
- What have I observed? I’m also being labeled: incompetent, unaware of customer needs, undisciplined, idealist.
- However, what I am proposing is a natural evolution for Agile (from my point of view). Simply, in my experience #NoEstimates is the natural way to implement two of the 4 Agile Values: Customer collaboration over Contract negotiation; Respond to change over following a plan.
- Estimates enforce a plan, but what if you find a better way to develop that project? Should you stick to the old plan and be late (guaranteed!) or change your plan and make those estimates obsolete? Estimates marry you to a plan.
- And how about discovering what is really important? When you estimate you assume a certain meaning and value for the stories or requirements you are developing. What if your understanding changes? Do you go back and discuss all the estimates again? Or do you just continue because we’ve already planned this in anyway? #NoEstimates is about focusing on what matters, what is the next most important thing to do? Instead of trying to guess at all the things we need to do *and* spending a lot of time trying to guess how long they will take to implement.
- We started adopting Agile because we want to focus on what matters. Not on accessory, unnecessary work. Remember, BDUF was once considered essential and even critical for successful software projects. (some say it still is). As an advocate of #NoEstimats I feel like Christopher Columbus did. I know how to balance the egg, and once you experience the solution you too will understand how obvious it was. But no-one can see it before trying it. “having been told that discovering the Americas was no great accomplishment” Retrospective Coherence, my great nemesis (aka Common Sense)
- These are rules I’ve developed over time based on the SPC rules based on the work by Deming and Shewart: 1- Velocity (in # of stories) falls outside the control limit more than 3 times in a row (”outside limits”) 2- There are 5 or more points in sequence (ascending or descending) (”Run test”) - You could have a lot more rules and I encourage you to develop these rules for yourself based on your understanding of SPC and your knowledge of your system. So, let’s take a look at some projects....
- Let’s take a look at one example of how we can use #NoEstimates in a real project and what were the results...
- Here are the questions that I started with...
- Here are the questions that I started with...
- Chaos report, 2004
- It is far more likely for a project to be late, than to be on time (Parkison’s law) “Work expands so as to fill the time available for its completion.”
- I’ve seen the world from above. The Earth is really round. If we go west we will reach India! As Christopher Columbus did, I also know I’m wrong. But maybe in 500 years people will look back and understand why it is necessary to be wrong and experiment to evolve our industry and profession, not stick to what we know does not work well!
- Agile is alive and kicking. Take #NoEstimates and experiment! Be Agile!