Do My Requirements
Look Big In This?
#NoEstimates

Gerard Beckerleg
Solution Architect

Live Backchannel: #NETUG #NoEstima...
“Is there is a way to work, where the software you write
ends up being valuable, and the business people you work
with end...
About me



Gerard Beckerleg



Solution Architect at SSW





SSW Scrum White Robe
Agile
Automated testing
Continuo...
Do My Requirements Look
This?

BIG In
Agenda



Background



Why estimate?



Problems with software estimation



Are there any alternatives?



Discussi...
What is an estimate?


verb (used with object), es·ti·mat·ed, es·ti·mat·ing.

1. to form an approximate judgment or opini...
What is an estimate?



“A good estimate is an estimate that provides a clear
enough view of the project reality to allow...
1. Why estimate?
What problem does estimating solve?



“the business as a whole is trying to make a decision —
about how to spend it’s mo...
What’s the best thing to do when
faced with uncertainty?


Seek information
Project x
Cost 20,000

Development

Value 50,000
Decision: BUILD IT
Project y
Cost 60,000
Value 50,000

Decision: DON’T BU...
100,000
2. Problems with software estimation
Vacations
Holidays
Sick days
Training
Weekends
Company meetings
Department meetings
Setting up new workstations
Installing...
Management of beta test program
Participation in technical reviews
Integration work
Processing change requests
Attendance ...
Functional Requirements Areas
Setup/installation program
Data conversion utility
Glue code needed to use third-party or
op...
Effect of personnel factors on project effort
21st Century

20th Century
Overestimation
Is it better to over or underestimate?
Requirements



“Until each specific feature is understood in detail, it's
impossible to estimate the cost of a software ...
We usually estimate at the start of a project
when we have the least amount of knowledge.

The Cone of Uncertainty
Suppose you're developing an order-entry system
and you haven't yet pinned down the requirements
for entering telephone nu...
We need everything in the spec!” … tick tock …
“We don’t need that … that can wait … this can be
simpler … I forgot what t...
The Result


“something based on an unrealistic list of requirements,
using weak estimates, made at the moment of maximum...
http://drewchialauthor.com
3. Are there any alternatives?
“People do not need umbrellas.
They need a way to stay dry on a rainy day.”
Neil Killick
Example - Budgeting a new project


New Subscription Web App



How many people will be interested? What percentage of
p...
Example - Budgeting a new project



Team costs 10,000 per week



Business has 500,000



MVP after 9 months



…this...
Example - Budgeting a new project


Work for 2 weeks (20,000)



Start work on the most important, most risky, most info...
Risk Estimation Method



Sequence the work to get as much information as
possible



Attack the bigger risks first



...
Work in progress



Limit your team’s WIP



Measure throughput



Little’s Law to calculate lead times
Whenever you feel the urge to start a
large project


Stop



Ask yourself, what can I deliver tomorrow that is
valuable...
100,000
Acknowledgements


Neil Killick @neil_killick



Kent Beck @KentBeck



Ron Jeffries @RonJeffries



Bob Martin @uncle...
References Part 1


http://xprogramming.com/articles/the-noestimates-movement/



http://www.cio.com/article/742684/_No_...
Reference Part 2


http://pragprog.com/magazines/2013-02/estimation-is-evil



http://www.youtube.com/watch?v=rrkrvAUbU9...
Thank You!
Sydney | Melbourne | Brisbane | Adelaide

info@ssw.com.au

www.ssw.com.au

Delivering Awesome Web Applications
3 things
•

@gerardbeckerleg

•

GerardBeckerleg@ssw.com.au

•

http://gerardbeckerleg.wordpres
s.com

Delivering Awesome ...
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
#NoEstimates - Stop lying to yourself and your customers, and stop estimating
Upcoming SlideShare
Loading in …5
×

#NoEstimates - Stop lying to yourself and your customers, and stop estimating

2,423 views

Published on

After his successful session last year on Agile Scrum, our resident Scrum White Robe Gerard Beckerleg is at it again, except this time he's taking on one of the most divisive topics in software development: Estimation.

In this video recorded at the Sydney SSW offices, Gerard Beckerleg takes a dive into the depths of this controversial topic and extracts the most interesting ideas and raises some very difficult questions about the big white elephant in the room that is Software Estimation.

After examining the pros and cons of estimation Gerard lays the blueprint for a better way to help you and your clients get what they are really looking for.

Published in: Technology
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,423
On SlideShare
0
From Embeds
0
Number of Embeds
814
Actions
Shares
0
Downloads
39
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide
  • What I am about to tell you is the result of my research into estimates over the passed couple of months
  • ContextAgileSmall to medium green field project
  • If we were to find out estimates have no value, what would we do?What problem do estimates solve, exactly? What other ways are there to solve the problem?Could time be spent doing other more valuable tasks?#NoEstimates is not about ditching estimates. It is about improving the way we work such that estimates become redundant.
  • How to deliver as much value as much possible, within budgetHow to start generating positive cash flow before they run out of moneyAll value does not come at the end
  • The ultimate developmentanti-patternThen we demand that the developers “estimate” when they’ll be done with all this stuff. They, too, know less about this product than they ever will again, and they don’t understand most of these requirements very well. But they do their best and they come up with a date. Does the business accept this date? Of course not! First of all, it’s only an estimate. Second, clearly the developers would leave themselves plenty of slack—they always do. Third, that’s not when we want it. We want it sooner.So we push back on the developers’ estimate, leaning harder and harder until we’re sure we’ve squeezed out all the fat they left in there. Sometimes we even just tell them when they have to be done.Either way, the developers leave the room, heads down, quite sure that they have again been asked to do the impossible. And the business people write down the date: “Development swears they’ll be done November 13th at 12:25PM.”
  • Are you forgetting anything?
  • How do you factor in the unknowns?
  • Who is going to do the work?Can you estimate on behalf of other people?Do you average out across all team members or assign tasks?
  • Individual performance varies by a factor of 10 or moreEffect of personnel factors on project effort. Depending on the strength or weakness in each factor, the project results can vary by the amount indicated—that is, a project with the worst requirements analysts would require 42% more effort than nominal, whereas a project with the best analysts would require 29% less effort than nominal.The magnitude of these factors from the Cocomo II model is confirmed by numerous studies since the 1960s that show 10:1 to 20:1 differences in individual and team performance (Sackman, Erikson, and Grant 1968; Weinberg and Schulman 1974; Curtis 1981; Mills 1983; Boehm, Gray, and Seewaldt 1984; DeMarco and Lister 1985; Curtis et al. 1986; Card 1987; Boehm 1987b; Boehm and Papaccio 1988; Valett and McGarry 1989; Boehm et al. 2000).
  • Optimism.In a study of 300 software projects, Michiel van Genuchten reported that developer estimates tended to contain an optimism factor of 20% to 30% (van Genuchten 1991)
  • Treating estimates as promises leads to conservative teams and disappointing results."When a measure becomes a target, it ceases to be a good measure.“Goodhart's law"As soon as a metric becomes a measure, it will be gamed. There are no exceptions.“ Ron Jeffries
  • Estimates as a weaponDamage to the relationshipDamage to moraleEffect on future estimatesBlameExperience has taught me that "Waterfall" is code for "write everything down in a _RD doc nobody reads so we know who to blame“@Carnage4Life
  • The effect on creativity(1945) Dunkers candle problemDan Pink: The puzzle of motivationhttp://www.youtube.com/watch?v=rrkrvAUbU9YYour job is to attach the candle to the wall so the wax does not drip onto the table
  • Overcome functional fixedness, see the box as something else.Sam Gluxberg from PrincetonTop 25% $5 top 25$ nice motivator3.5 minutes longer, dulls thinking and blocks creativity. Repeated for 40 years.
  • Carrot and stick If-then works with simple set of rules and clear goal.If then works with simple set of rules and clear goal.
  • Great for 20th century tasks bad for 21st
  • Is it better to over or underestimate?Reduced effectiveness of project plansStatistically reduced chance of on-time completionPoor technical foundation leads to worse-than-nominal resultsDestructive late-project dynamics make the project worse than nominal
  • Single Point EstimatesSoftware estimates are routinely presented as single-point numbers, such as "This project will take 14 weeks." Such simplistic single-point estimates are meaningless because they don't include any indication of the probability associated with the single point. They imply a probability as shown in Figure 1-1—the only possible outcome is the single point given.
  • Problem with ranges, add rule
  • 1906 statistician Francis Galton observed a competition to guess the weight of an ox at a country fair. 800 entered. Galton, being the kind of man he was, ran statistical tests on the numbers. He discovered that the average guess (1,197lb) was extremely close to the actual weight (1,198lb) of the ox. This story was told by James Surowiecki, in his entertaining book The Wisdom of Crowds.
  • Albert Lederer and Jayesh Prasad found that the most commonly used estimation technique was comparing a new project with a similar past project, based solely on personal memory. This technique was not found to be correlated with accurate estimates. The common techniques of "intuition" and "guessing" were found to be correlated with cost and schedule overruns (Lederer and Prasad 1992). Numerous other researchers have found that guessing, intuition, unstructured expert judgment, use of informal analogies, and similar techniques are the dominant strategies used for about 60 to 85% of all estimates (Hihn and Habib-Agahi 1991, Heemstra and Kusters 1991, Paynter 1996, Jørgensen 2002, Kitchenham et al. 2002).
  • Most of us were taught to write down all our requirements at the very beginning of the project. There are only three things wrong with this: “requirements,” “the very beginning,” and “all.” At the very beginning, we know less about our project than we’ll ever know again. This is the worst possible moment to be making firm decisions about what we “require.”Ron Jeffries
  • Suppose you're developing an order-entry system and you haven't yet pinned down the requirements for entering telephone numbers. Some of the uncertainties that could affect a software estimate from the requirements activity through release include the following:
  • Misunderstanding requirements
  • Anyone who has ever looked at a list of “requirements” has seen some items that were very important, and some that were—well—not so important. Not so important like 1/100th as important as the most important things. Not so important like downright bad ideas. There is a very strong “80-20” rule at work in requirements lists. The bulk of the value comes from a very small subset of the so-called requirements. So these other things aren’t “requirements” at all. They’re ideas, and some of them are not very good. How could they all be good? We made them up before we began the project, when we knew the least.
  • "Requirements have a "best before" date and expire."
  • Estimates drive a wedge between business and development
  • Put uncertainty and risk at the centre of a conversation between the developers & the rest of the business
  • Treating projects as experiments
  • Ref book
  • To not wait 9 months to deliver a solution but to deliver a solution in 1 month, then make it better.After each “iteration” we will not have a holistic view of what we’re building.
  • They adjust their outlook frequently, and adjust what they work on next in accord with what is happening.
  • Automate as much as possible
  • There is so much to consider when we try and measure value. Aside from the empirical measure of monetary returns, we have to consider the needs of the customers, the stakeholders and our corporate strategy (to name but a few), not to mention the fact that all of these things change over time.Ferrari example
  • The ultimate developmentanti-patternThen we demand that the developers “estimate” when they’ll be done with all this stuff. They, too, know less about this product than they ever will again, and they don’t understand most of these requirements very well. But they do their best and they come up with a date. Does the business accept this date? Of course not! First of all, it’s only an estimate. Second, clearly the developers would leave themselves plenty of slack—they always do. Third, that’s not when we want it. We want it sooner.So we push back on the developers’ estimate, leaning harder and harder until we’re sure we’ve squeezed out all the fat they left in there. Sometimes we even just tell them when they have to be done.Either way, the developers leave the room, heads down, quite sure that they have again been asked to do the impossible. And the business people write down the date: “Development swears they’ll be done November 13th at 12:25PM.”
  • #NoEstimates - Stop lying to yourself and your customers, and stop estimating

    1. 1. Do My Requirements Look Big In This? #NoEstimates Gerard Beckerleg Solution Architect Live Backchannel: #NETUG #NoEstimates Delivering Awesome Web Applications
    2. 2. “Is there is a way to work, where the software you write ends up being valuable, and the business people you work with end up being happy?” Dan Milstein "#NoEstimates is not about ditching estimates. It is about improving the way we work such that estimates become redundant.“ Neil Killick
    3. 3. About me  Gerard Beckerleg  Solution Architect at SSW     SSW Scrum White Robe Agile Automated testing Continuous delivery
    4. 4. Do My Requirements Look This? BIG In
    5. 5. Agenda  Background  Why estimate?  Problems with software estimation  Are there any alternatives?  Discussion
    6. 6. What is an estimate?  verb (used with object), es·ti·mat·ed, es·ti·mat·ing. 1. to form an approximate judgment or opinion regarding the worth, amount, size, weight, etc., of; calculate approximately: to estimate the cost of a college education. 2. to form an opinion of; judge. verb (used without object), es·ti·mat·ed, es·ti·mat·ing. 3. to make an estimate. Noun 4. an approximate judgment or calculation, as of the value, amount, time, size, or weight of something. 5. a judgment or opinion, as of the qualities of a person or thing. 6. a statement of the approximate charge for work to be done, submitted by a person or business firm ready to undertake the work. Dictionary.com
    7. 7. What is an estimate?  “A good estimate is an estimate that provides a clear enough view of the project reality to allow the project leadership to make good decisions about how to control the project to hit its targets.” Steve McConnell
    8. 8. 1. Why estimate?
    9. 9. What problem does estimating solve?  “the business as a whole is trying to make a decision — about how to spend it’s money (your time)” Dan Milstein  Businesses need certainty about what they will get and when  Unfortunately for most businesses there is very rarely any certainty in software design and development
    10. 10. What’s the best thing to do when faced with uncertainty?  Seek information
    11. 11. Project x Cost 20,000 Development Value 50,000 Decision: BUILD IT Project y Cost 60,000 Value 50,000 Decision: DON’T BUILD IT Business
    12. 12. 100,000
    13. 13. 2. Problems with software estimation
    14. 14. Vacations Holidays Sick days Training Weekends Company meetings Department meetings Setting up new workstations Installing new versions of tools on workstations Troubleshooting hardware and software problems Ramp-up time for new team members Mentoring of new team members Management coordination/manager meetings Cutover/deployment Data conversion Installation Customization Requirements clarifications Maintaining the revision control system Supporting the build Maintaining the scripts required to run the daily build Maintaining the automated smoke test used in conjunction with the daily build Installation of test builds at user location(s) Creation of test data Steve McConnell
    15. 15. Management of beta test program Participation in technical reviews Integration work Processing change requests Attendance at change-control/triage meetings Coordinating with subcontractors Technical support of existing systems during the project Maintenance work on previous systems during the project Defect-correction work Performance tuning Learning new development tools Administrative work related to defect tracking Coordination with test (for developers) Coordination with developers (for test) Answering questions from quality assurance Input to user documentation and review of user documentation Review of technical documentation Demonstrating software to customers or users Demonstrating software at trade shows Demonstrating the software or prototypes of the software to upper management, clients, and end users Interacting with clients or end users; supporting beta installations at client locations Reviewing plans, estimates, architecture, detailed designs, stage
    16. 16. Functional Requirements Areas Setup/installation program Data conversion utility Glue code needed to use third-party or open-source software Help system Deployment mode Interfaces with external systems Steve McConnell
    17. 17. Effect of personnel factors on project effort
    18. 18. 21st Century 20th Century
    19. 19. Overestimation
    20. 20. Is it better to over or underestimate?
    21. 21. Requirements  “Until each specific feature is understood in detail, it's impossible to estimate the cost of a software project accurately” Steve McConnell  Not very agile
    22. 22. We usually estimate at the start of a project when we have the least amount of knowledge. The Cone of Uncertainty
    23. 23. Suppose you're developing an order-entry system and you haven't yet pinned down the requirements for entering telephone numbers. • When telephone numbers are entered, will the customer want a Telephone Number Checker to check whether the numbers are valid? • If the customer wants the Telephone Number Checker, will the customer want the cheap or expensive version of the Telephone Number Checker? (U.S.-only versus international phone numbers.) • If you implement the cheap version of the Telephone Number Checker, will the customer later want the expensive version after all? • Can you use an off-the-shelf Telephone Number Checker, or are there design constraints that require you to develop your own? • How will the Telephone Number Checker be designed? • How long will it take to code the Telephone Number Checker? • Do the Telephone Number Checker and the Address Checker interact? How long will it take to integrate the Telephone Number Checker and the Address Checker? • What will the quality level of the Telephone Number Checker be? • How long will it take to debug and correct mistakes made in the implementation of the Telephone Number Checker?
    24. 24. We need everything in the spec!” … tick tock … “We don’t need that … that can wait … this can be simpler … I forgot what that is!  “When we write down our “requirements,” we act like this is our very last chance to ask for anything. So we ask for everything we can think of, everything we might need. We’re pretty sure we won’t get it all anyway, so let’s ask for a lot and hope we get something we can live with.” Ron Jeffries
    25. 25. The Result  “something based on an unrealistic list of requirements, using weak estimates, made at the moment of maximum ignorance, by people who are always optimistic about their own abilities. It has been squeezed down by managers who think they need to be tough, and sometimes it is just overridden by someone who has made a rash promise to someone higher up the food chain.” Ron Jeffries
    26. 26. http://drewchialauthor.com
    27. 27. 3. Are there any alternatives?
    28. 28. “People do not need umbrellas. They need a way to stay dry on a rainy day.” Neil Killick
    29. 29. Example - Budgeting a new project  New Subscription Web App  How many people will be interested? What percentage of prospects will turn into subscribers? How much will subscribers pay for the product? Business  How much of this product can we get done, by what date, for how much money? Development  Can we begin to bring in enough money to stay alive before our cash runs out? Need certainty
    30. 30. Example - Budgeting a new project  Team costs 10,000 per week  Business has 500,000  MVP after 9 months  …this is a big risk
    31. 31. Example - Budgeting a new project  Work for 2 weeks (20,000)  Start work on the most important, most risky, most informative parts of the product  Gain better understanding of how hard it is and how long things take  Business will see it working  If after two weeks, things look bad, we’ll know it and we’ll recommend the business stops  If things look good so far, we’ll decide together what the next major decision point will be. It might be a month out, or three months out
    32. 32. Risk Estimation Method  Sequence the work to get as much information as possible  Attack the bigger risks first  Offer choices
    33. 33. Work in progress  Limit your team’s WIP  Measure throughput  Little’s Law to calculate lead times
    34. 34. Whenever you feel the urge to start a large project  Stop  Ask yourself, what can I deliver tomorrow that is valuable?
    35. 35. 100,000
    36. 36. Acknowledgements  Neil Killick @neil_killick  Kent Beck @KentBeck  Ron Jeffries @RonJeffries  Bob Martin @unclebobmartin  Dan Milstein @danmil  Vasco Duarte @duarte_vasco  Woody Zuill @WoodyZuill  Chris R. Chapman @DerailleurAgil  Steve McConnell no twitter????
    37. 37. References Part 1  http://xprogramming.com/articles/the-noestimates-movement/  http://www.cio.com/article/742684/_No_Estimates_in_Action_5_Ways_to_Rethink_Software_Projects  http://pragprog.com/magazines/2013-04/estimation  http://neilkillick.com/category/noestimates/  http://derailleurconsulting.com/blog/how-to-run-the-noestimates-puzzle-experiment-v10  http://www.codinghorror.com/blog/2006/06/how-good-an-estimator-are-you.html  http://www.codinghorror.com/blog/2006/07/how-good-an-estimator-are-you-part-ii.html  http://www.amazon.com/exec/obidos/ASIN/0735605351  http://www.stevefenton.co.uk/Content/Blog/Date/201401/Blog/The-No-Estimates-Debate-Distraction/  http://gothandy.wordpress.com/2013/05/19/noestimates-is-a-good-idea/ Delivering Awesome Web Applications
    38. 38. Reference Part 2  http://pragprog.com/magazines/2013-02/estimation-is-evil  http://www.youtube.com/watch?v=rrkrvAUbU9Y  http://www.amazon.com/gp/product/1935401009  http://www.amazon.com/gp/product/0884271951  http://www.amazon.com/gp/product/0307887898  https://www.facebook.com/notes/facebook-engineering/software-design-glossary/10150309412413920  http://www.amazon.com/gp/product/0321278658  http://www.amazon.com/gp/product/1452654204  http://usersknow.blogspot.com/  http://www.amazon.com/gp/product/1449334911  http://blog.hut8labs.com/no-deadlines-for-you.html
    39. 39. Thank You! Sydney | Melbourne | Brisbane | Adelaide info@ssw.com.au www.ssw.com.au Delivering Awesome Web Applications
    40. 40. 3 things • @gerardbeckerleg • GerardBeckerleg@ssw.com.au • http://gerardbeckerleg.wordpres s.com Delivering Awesome Web Applications

    ×