No estimates - a controversial way to improve estimation with results-handouts
•Download as PPTX, PDF•
15 likes•2,977 views
Often we hear that estimating a project is a must. "We can't make decisions without them" we hear often. In this session I'll present examples of how we can predict a release date of a project without any estimates, only relying on easily available data. I'll show 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 and 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.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (17)
Similar to No estimates - a controversial way to improve estimation with results-handouts
Similar to No estimates - a controversial way to improve estimation with results-handouts (20)
More from Vasco Duarte
More from Vasco Duarte (18)
Recently uploaded
Recently uploaded (20)
No estimates - a controversial way to improve estimation with results-handouts
- 1. #NoEstimates Vasco Duarte @duarte_vasco A way to improve estimates that gives you results!
- 2. Learn more about NoEstimates: • How it can help you turn around a failing project • How it can help you show what is possible and stick to that • How it can help you find very early if you are late (and get your manager, or customer, to believe you) • How to apply #NoEstimates without threatening anyone Become a Beta Reader and get the book for free! http://NoEstimatesBook.com
- 3. Vasco Duarte @duarte_vasco http://bit.ly/vasco_blog http://bit.ly/vasco_slideshare http://NoEstimatesBook.com Vasco.Duarte@oikosofy.com
- 9. #NoEstimates
- 11. pictoquotes
- 12. Kent Beck – Extreme Programming
- 13. Ken Schwaber - Scrum
- 14. Taiichi Ohno – Toyota Production System
- 15. Edwards W. Deming – Everything above...
- 16. “If I have seen further it is by standing on the shoulders of giants” - Isaac Newton
- 21. Just Google it
- 23. Customer Collaboration over Contract Negotiation Responding to Change over Following a Plan
- 27. #NoEstimates How-to 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
- 28. Is the system of development stable? (ref: SPC)
- 29. I AM GOING TO GO AHEAD AND ASK YOU TO DELIVER 10 STORIES NEXT SPRINT...
- 30. 10 9 8 7 6 5 4 3 2 1 0 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
- 31. WTF!!!!! !#%&!
- 32. Can we use the data we observe to predict the system throughput and detect changes that affect system stability?
- 33. System stability rules 1.Velocity outside limits 3 times in a row (“outside limits”) 2.There are 5 or more points in sequence (“run test”) More in the 1-day #NoEstimates Workshop Information by email: vasco.duarte@oikosofy.com
- 34. 12 10 8 6 4 2 0 1 3 5 7 9 11 13 15 17 19 21 Team: AT # of items/stories delivered LCL UCL average 12 10 8 6 4 2 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Team: RF LCL UCL average # of items/stories delivered 20 18 16 14 12 10 8 6 4 2 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 Team: RF2 LCL UCL average # of items/stories delivered 25 20 15 10 5 0 1 3 5 7 9 11 13 15 17 19 21 Team: SH # of items/stories delivered LCL UCL average
- 35. 17 15 13 11 9 7 5 3 1 -1 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 Team: K LCL UCL average 16 14 12 10 8 6 4 # of items/stories delivered 2 0 1 2 3 4 5 6 7 8 Team: MPC # of items/stories delivered LCL UCL average 16 14 12 10 8 6 4 2 0 1 2 3 4 5 6 7 8 9 1011121314151617181920 Team: AS 30 25 # of items/stories delivered LCL UCL average 20 15 10 5 0 1 2 3 4 5 6 7 8 9 10 Team: FC # of items/stories delivered LCL UCL average
- 37. Counting Stories vs. Estimated Story Points Q: Which ”metric” is more accurate when compared to what actually happened in the project?
- 38. A long project 24 Sprints
- 39. 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
- 40. Disclaimer... This is only one project! Find 21 more at: http://bit.ly/NoEstimatesProjectsDB
- 41. After just 3 sprints Story Points predictive power # of Stories 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%!
- 42. After just 5 sprints Story Points predictive power # of Stories 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%!
- 43. Q: Which ”metric” is more accurate when compared to what actually happened in the project?
- 44. But there is more...
- 46. #NoEstimates RegularEstimates “The chart is a snapshot of one team of 20+ teams over a 2 year period.” – Cory Foy
- 47. Which is more predictable ?
- 48. What difference does a Story Point make in a project that used both Story Points and #NoEstimates?
- 49. Next you will see the forecasted release date when using Story Points (values 1:3:5)
- 50. 68 Product Backlog Cumulative Flow Diagram 71 71 71 71 71 71 72 72 72 73 73 0 3 7 7 9 11 12 13 20 20 22 23 100 90 80 70 60 50 40 30 20 10 0 Remaining Done Linear (Remaining) Linear (Done) Release on 20th October 2014 1/3 1/17 1/31 2/14 2/28 3/14 3/28 4/11 4/25 5/9 5/23 6/6 6/20 7/4 7/18 8/1 8/15 8/29 9/12 9/26 10/10 10/24 11/7
- 51. Next you will see the forecasted release date when using Story Points (values 1:2:3)
- 52. 48 Product Backlog Cumulative Flow Diagram 51 51 51 51 51 51 52 52 52 53 53 0 2 5 5 7 8 9 10 15 15 17 18 80 70 60 50 40 30 20 10 0 Remaining Done Linear (Remaining) Linear (Done) Release on 14th October 2014 1/3 1/17 1/31 2/14 2/28 3/14 3/28 4/11 4/25 5/9 5/23 6/6 6/20 7/4 7/18 8/1 8/15 8/29 9/12 9/26 10/10 10/24 11/7
- 53. Next you will see the forecasted release date when #NoEstimates (or, all stories = 1 story point)
- 54. 28 31 31 31 31 31 31 32 32 32 Product Backlog Cumulative Flow Diagram 33 33 0 1 3 3 5 5 6 7 10 10 12 13 60 50 40 30 20 10 0 Remaining Done Linear (Remaining) Linear (Done) Release on 29th September 2014 1/3 1/17 1/31 2/14 2/28 3/14 3/28 4/11 4/25 5/9 5/23 6/6 6/20 7/4 7/18 8/1 8/15 8/29 9/12 9/26 10/10 10/24 11/7
- 55. Conclusion...
- 56. All dates within 3 weeks of each other in a 38 to 42 week project (a margin of ~8%)
- 57. ”At that point, I stopped thinking that estimating was important.” Bill Hanlon: http://bit.ly/BHanlon Data used with permission from Bill Hanlon at Microsoft
- 58. In 1986, Profs. S.D. Conte, H.E. Dunsmoir, and V.Y. Shen proposed that a good estimation approach should provide estimates that are within 25% of the actual results 75% of the time --Steve McConnel, Software Estimation: Demystifying the Black Art In this presentation you have seen examples that far outperform what estimation specialists consider a ”good estimation”. In common they have one way to look at work: #NoEstimates
- 59. #NoEstimates testimonial The deviation between estimated and actual velocity would have been approximately 15% lower if we would have used #NoEstimates. We have analyzed data from 50 Sprints… …at no time the story point based estimation was better than #NoEstimates.
- 61. 80% Late or Failed Source: Software Estimation by Steve McConnell
- 62. The larger the project, the bigger the problem Source: Software Estimation by Steve McConnell
- 63. Source: Software Estimation by Steve McConnell
- 64. Comparison of 17 projects ending between 2001 and 2003. (Average: 62%)
- 67. Take #NoEstimates and experiment! Learn, Be Agile!
- 68. Learn more about NoEstimates: • How it can help you turn around a failing project • How it can help you show what is possible and stick to that • How it can help you find very early if you are late (and get your manager, or customer, to believe you) • How to apply #NoEstimates without threatening anyone Become a Beta Reader and get the book for free! http://NoEstimatesBook.com
Editor's Notes
- There are some points in your life that call for life changing choices.
- You can choose the blue pill and the story ends (after this presentation), tomorrow you will wake up in your bed and believe what you want to believe.
- But you can take the red pill, and learn to love the machine – to see the machine, for what it is: a system that you are part of and you can learn to understand. Take the red-pill and a new journey starts, and I will show you how deep the rabbit hole goes. Remember: all I’m offering you here today is the truth…
- We’ve been fighting accepted truths in the field of software development for many, many years. Some of us can now see the matrix.
- But it was not always like this…
- We’ve been fighting accepted truths in the field of software development for many, many years.
- People will argue that #NoEstimates is nothing new, that they had done that in the past. Kind of like Agile, come to think of it. I don’t claim to be 100% original. That is not the point. I do claim that #NoEstimates works for me, and it can work for you! Most of all, it can improve our industry!
- 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. Today we know different. We know that Agile requires even more discipline than the old ways of developing software.
- 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). I propose to you that #NoEstimates is easy. So easy in fact, that I can explain it to you in 30 seconds or less.
- Select the most important piece of work you need to do (highest value first) Break that work down into risk-neutral chunks of work (each piece should be small enough that failing to deliver it at first attempt does not jeopardize the project objectives) Develop each piece of work Iterate and refactor (this step itself builds on practices that many still don’t believe in like Emergent Architecture where coding is a key/critical skill and cannot be delegated to keyboard monkeys) That is how easy it is.... Of course there are a few questions to answer before we can reliably apply this approach...
- One question comes from understanding that what we are trying to do here is learning to live without trying to impose control on the development system. The fact is that what makes sense to do will change as up learn more. It does not help to set a target outside a system's capability. In other words, if a system is stable and reliably churning out a certain output, it is of no use to set higher (or lower) targets for that system. Conversely, if the system is not stable, setting a target is useless because you cannot predict reliably enough the output of the system. Let me give you an example. Remember Office Space the movie that came out in 1999 (what a fitting year) and starred Jenifer Aniston, Ron Livingston and others?
- Here’s a scene from that movie: You know the boss, right? The one with the TPS report requests? This request he just made is pretty common. How many in the audience have been instigated to deliver just a bit more in the next Sprint? (show of hands). What if your team’s throughput looked like this:
- After this explanation I’m betting your reaction to the manager’s request would be:
- We have to learn to dance with the system, and #NoEstimates is one way to dance with the system. Just like when you don't drink milk because it messes with your system. My theory is that most software development is highly Estimates-intolerant, so estimates must be used with care and best avoided altogether. This led me to ask the question. Is the system of development ”stable”? Stable means (adapted to software based on my own observations) Can we use the data we observe (no estimates) to predict system throughput and detect changes that make the system unstable?
- 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...
- Here is a chart that Cory Foy posted on twitter just a few weeks ago.
- Agile is alive and kicking. Take #NoEstimates and experiment! Be Agile!
- Agile is alive and kicking. Take #NoEstimates and experiment! Be Agile!
- Agile is alive and kicking. Take #NoEstimates and experiment! Be Agile!
- Agile is alive and kicking. Take #NoEstimates and experiment! Be Agile!
- Agile is alive and kicking. Take #NoEstimates and experiment! Be Agile!
- Agile is alive and kicking. Take #NoEstimates and experiment! Be Agile!
- Agile is alive and kicking. Take #NoEstimates and experiment! Be Agile!
- Agile is alive and kicking. Take #NoEstimates and experiment! Be Agile!
- Just last week – as if prepared on purpose for Oredev…
- Chaos report, 2004
- I’ve seen Matrix. It is not the Estimate that bends, it is you. I and others have learned that in fact…
- Agile is alive and kicking. Take #NoEstimates and experiment! Be Agile! And because I know that you will ask “How can I get started”, I’ve prepared a gift for you. Something you get for being here at Oredev and in my talk.