60% of the Time, Estimates Are Right Every Time

Historically developers hate giving estimates because they are mostly wrong and are often held to them by the business. The business needs estimates because ultimately all projects cost money. What happens when the estimator leaves or the estimation is from months prior? How do we get developers and business to both get what they want?

Learn how to love the estimation process. This talk goes over doing estimation best practices. Learn how to transfer the estimation knowledge from estimator to the rest of the team. Keep business to scope and understanding change process.

Transcript

1. 60% of the Time, Estimates Are Right Every Time Brett Whittington, Senior Principal Consultant @ Slalom
2. About Me • Senior Principal Consultant • Consulting for 12 Years • Software Development for 20 years • @BrettTheWhitt • www.brettthewhitt.com
3. Taking You From an Estimating Zero to a Hero!
4. Agenda • Problems with Estimating • Needs and Wants • Types of Estimation • Opinionated Way To Estimate • Reporting Back to Business • Addressing Issues • Questions
5. Who Will Benefit From This Presentation? • Developers • Team Leads • Architects • Project Managers • Product Owners • Executives
6. The Scenario ABC Company sells a Software as a Service product that allows businesses to track its employees productivity in a non-invasive way using gamification. Organizations can create their own achievements that equate to perceived value and reward employees via awards, swag, bonuses, and PTO. Customers can implement achievement tracking into their own applications via ABC Company’s API.
7. ABC Company has… • A Novel Product • A Large Consumer Base • Software Development process using Agile and Azure DevOps • A large development team originally focused on maintenance and new features.
8. ABC Company’s Issues • Competitor’s have entered the market, copying many of the features and offering a lower price – taking market share • Innovation on the software has lagged due to maintenance tasks • New Features and Enhancements are beginning to take longer, and the development teams are continuously missing estimates and due dates. • Contention between product owners and development teams is starting to rise.
9. Goal: Retain and Acquire New Customers ABC Company wants to implement one of three new solutions to achieve its goals.
10. Solution #1 Implementing gamification integration can take significant work in customers’ solutions. ABC Company wants to enhance the current solution so that it is easier to implement so that start up costs for the customer are less expensive.
11. Solution #2 ABC Company wants to implement a new feature will help companies create new achievements by using AI & ML to review employee activity. This would allow customers to use ABC Company’s product with less management.
12. Solution #3 ABC Company wants to integrate its product in a new way with popular online retailers so that user’s can use rewards to purchase goods at a discount.
13. Risks • No innovation = ABC Company will continue to lose market share • Development Effort vs Business Value is unknown. • Unknown Timeline For Marketing Solution • Unknown Forecasting of Expected Reward
14. When Business Wants an Estimate As Business Team: • Risk Reduction • Total Costs • Estimated Business Value As Development Team: • Delivering on promises • Requirements • Quality
15. Business vs Development
16. Contention Creates Friction Leading to these common quotes!
17. “Estimates Are Lies”
18. “Business uses my estimates against me”
19. “You’re just going to double it!”
20. “I feel judged when giving an estimate during planning.”
21. “Why should I estimate if you aren’t going to use it?”
22. Can you guess who said all these things?
23. This Guy Who has two thumbs?
24. Have you said anything similar?
25. All these quotes have something in common.
26. Broken Trust
27. What does Business Want?
28. Back to the Scenario • Solution 1 – Core Innovation • Solution 3 – New Opportunities • Solution 2 – Market Disrupting
29. Solution #1 Implementing gamification integration can take significant work in customers’ solutions. ABC Company wants to enhance the current solution so that it is easier to implement so that start up costs for the customer are less expensive. Gut Check: • Feels Less Expensive • Feels Less Impactful
30. Solution #2 ABC Company wants to implement a new feature will help companies create new achievements by using AI & ML to review employee activity. This would allow customers to use ABC Company’s product with less management. Gut Check: • Feels Very Expensive • Feels Impactful
31. Solution #3 ABC Company wants to integrate its product in a new way with popular online retailers so that user’s can use rewards to purchase goods at a discount. Gut Check: • Feels Inexpensive • Feels Impactful
32. How does this relate to Estimation? Business Often Underestimates Effort IT Project Development Lifecycle Often Misunderstood Goals Set Without Understanding Effort Goals are Considered Bullseyes and Not Buoys Side Bar: Bonuses are Based on Goals
33. Problems with Estimating
34. Product Owner • Goals Change • Side Quests Interrupt Main Quest • Success Criteria Changes • Estimates not consistent from development team
35. Project Manger • Work Not Estimated Consistently • Traceability of Work Isn’t Captured • Risks Associated With Work Not Captured • Known Issues with Work Not Captured
36. Team Lead / Architect • Requirements not detailed • Goals Not Clearly Understood • No Defined Success Criteria • Individual Developers Perform Differently • Limited Expertise
37. Team Member • Requirements not detailed • Goals not communicated or communicated poorly. • Estimating Risks and Not the Work • Afraid of Being Wrong
38. Going from This To This
39. What Development Teams Can Do!
40. Product Owner / Project Manager Needs Total Costs Estimated Business Value Expertise Required Roles Requirements Risk Reduction
41. Architect / Team Lead / Developer Needs Fulfillment from delivering on promises Providing a Consistent Way to Estimate Work on a single project Creating a Consistent Way to Compare Projects Identifying what is necessary to be built and the path to do it
42. Deny The Following Feelings Imposter Syndrome Not Worth My Time Distracting From Other Work Incorrect Outcomes Just Double My Gut
43. Estimating Work
44. Before We Begin We need to be able to do 3 things: 1. Review 2. Assess 3. Communicate
45. Review What does business want and why it is important to them What are the business objectives?
46. Review What are the business objectives? What are the success criteria?
47. Review – Scenario #1 Implementing gamification integration can take significant work in customers’ solutions. ABC Company wants to enhance the current solution so that it is easier to implement so that start up costs for the customer are less expensive.
48. Review – Scenario #1 - Objectives SIMPLIFY ONBOARDING REDUCE IMPLEMENTATION COSTS REDUCE ABC COMPANY SUPPORT COSTS
49. Review – Scenario #1 - Objectives Why? By reducing the barrier to entry, the decision to work with us vs our competitors because easier. Because the barrier of entry is lowered, as a company, we will be required to respond to less support inquiries. • More Customers • Less non-valuable effort.
50. Assess – Scenario #1 • What are we building? • What technologies and patterns? • Will all or some of it be built, bought, or leveraging existing code? • What are the integrations? • How do these things affect an estimate?
51. Assess – Scenario #1 Why? By explicitly stating what we are building we now can communicate from a development perspective what we are building, how we are building it, what we are using to building it, and outcomes of using those methods. • Explains Approach to Business and Development Teams • Describes how the team plans to build the feature to business and development team.
52. Communicate – Scenario #1 Take everything created so far back to business and validate everything we just created. Why? • Aligns Development Understanding With Business • Forms the Basis of the Contract between IT and Business • A Point in Time Everyone Is Happy!
53. Types of Estimation
54. Top-down Estimation • Starts with a timeframe and deadline • Divides a project into discrete phases and tasks until every detail is accounted for. • Good – Can quickly determine if a project can meet a deadline. • Bad – Details are often missed.
55. Bottom-up Estimation • Start with the details • Group Details • Apply groups to phases • Good – Much more accurate • Bad – Takes a ton more time to get right
56. Analogous / Comparative Estimation • Compares project of similar types with one another. • Commonly used in Agile for assigning Story Points • Good – Very Accurate with lots of projects or experienced teams • Bad – With little history or inexperience teams lead to widely ranging estimates.
57. Parametric Estimation • Analogous Comparative Estimation with Science • Good – Extremely effective with an established process. • Bad – With little history or inexperience teams lead to widely ranging estimates.
58. Three Point Estimation • Add Wiggle Room on complex tasks or teams with far ranging experience levels. • Estimate via most likely, best, and worst cases • Good – Can give a more accurate estimate by applying little bits of contingency on each task • Bad – It can be too convenient to SWAG the best and worst cases.
59. Best Way to Estimate Use All The Methods!
60. Requirements! AAAAAAAAAAAAAAAAAaaaaaaaaaaaaaaa ahhhhhhhhhh!!!
61. Top Down / Bottoms Up
62. Grouping Like Requirements Requirements are often Brain Dumps with no organizations Group Requirements that are related. Identify Shared Components
63. Top/Down These become our Epics and Features
64. When To Stop!
67. Bottom / Up • Create Stories Based on Requirements • Note Requirements in Story to Provide Traceability • Provide Detailed Thoughts on what is In Scope, Out of Scope, and Assumptions You are Making
68. Consider… Requirement • A profile form that would allow the system to collect information about the person so that we can reach out with special offers in the future Scope: Good • A web form that has textboxes to collection information and checks that that required fields are entered.
69. Consider… Requirement • A profile form that would allow the system to collect information about the person so that we can reach out with special offers in the future Scope: Better • An Angular form that has 5 textboxes to collect information and validated that that required fields are entered, and the email address is a valid email address.
70. Consider… Requirement • A profile form that would allow the system to collect information about the person so that we can reach out with special offers in the future Scope: Best • An Angular form that has 5 textboxes to collects the following information and validated that that required fields are entered, and the email address is a valid email address. • Name • Address • Email • Phone • Birthdate
71. Consider… Requirement • A profile form that would allow the system to collect information about the person so that we can reach out with special offers in the future Out of Scope: Typical
72. Consider… Requirement • A profile form that would allow the system to collect information about the person so that we can reach out with special offers in the future Out of Scope • More than the planned 5 fields and validations changes the complexity of said form and would require re-estimation
73. Consider… Requirement • A profile form that would allow the system to collect information about the person so that we can reach out with special offers in the future Assumptions: Typical
74. Consider… Requirement • A profile form that would allow the system to collect information about the person so that we can reach out with special offers in the future Assumptions: • Assumption is to use out of the box Angular functionality. Reviewed using an off the shelf product such as JotForms but decided against because of XYZ.
75. What Assumptions are you making? Most Important Part! • Might be weeks, months, or year before actual work get started. • Written Description of What You Were Thinking About • Gives Team the ability to see your thoughts • PROTECTS YOU when Business tries to increase meaning and Scope
76. Tasks for Stories • Break down business requirements into development tasks. • Classify each task as being either simple, medium or complex.
77. Decide What Technology Layers Story Touches Application Layers HTML/CSS JavaScript Component JavaScript Service API Business Layer Infrastructure Database
78. Count the Amount of Widgets
79. Widgets As Stories and Tasks
80. If you haven’t noticed yet… We haven’t even started talking about hours, we’re just counting how many widgets we need to build.
81. We Don’t Care About Hours/T-Shirts Yet! WRITE OUT OUR UNDERSTANDING OF THE STORY WHAT IS “IN SCOPE” WHAT IS “OUT OF SCOPE” WHAT ASSUMPTIONS ARE YOU MAKING?
82. Scope in Practice
83. Now We Can Talk About Hours
84. Applying Hours To Our Widgets
85. Multiply it by our Number of Widgets
86. Tips/Tricks Story > 1 Week of Effort is too big and can likely be made smaller Stories That Need Expertise in 1 Area probably should be split out. If a Story has a ton of widgets = Too Big
87. Tips/Tricks If there are more than 3 widgets counted in a layer = more stories Shared Components should only be counted once Some requirements are not business requirements
88. What About All The Other Stuff? Planning Analysis Design Build Testing Deployment Team Leadership Project Management
89. Plan / Analyze / Design Planning – 10-15% of Total Build Time • This allows PM’s to put together project plans and staffing Analyze – 20% - 30% of Total Build Time • This allows the Team Leads / Architects / and BA’s to build out the requirements for the project. Design – 40-50% of Total Build Time • Allows Designers / Team Leads / Architects to put together the architecture, examples, run ways for the rest of the team to use for work.
90. Build This is total amount of time that developers on the team have hands on keyboard Includes the Following: • Self Estimating • Writing Code • Unit Testing • Dev Testing This effort is built on Widgets.
91. Testing / Deployment Testing – 85% - 100% of Total Build Time • Includes Time for QA to prepare and execute test • Includes Time for Developers to fix bugs Deployment – 5% to 10% of Total Build Time • Includes Time for Operations and Developers to Create CI/CD pipelines and infrastructure.
92. Team Leadership / Project Management Project Management – 20% - 40% of Total Build Time • Time for Project Managers to manage the team and report on Status Leadership – 5% - 10% of Total Build Time • Time for anyone else involved in the project Padding ☺ - 10% - 30% of Total Build Time • Time needed for Technical Spikes, Scope Change, Etc.
93. Based on 100-hour Build Time = Total 315 hrs. • Plan – 10hrs • Analyze – 20hrs • Design – 40hrs • Build – 100hrs • Test – 85hrs • Deploy – 20hrs • Project Management – 20hrs • Leadership – 10hrs • Contingency – 10hrs
94. This Sounds A Lot Like Waterfall Except these are just estimates and things change as time passes.
95. How to Report Back to Business
96. Now you have a “Finished” Estimate… Have a Detailed List of Estimated Work Scope Assumptions Estimated Hours/Story Points Based on Roles
97. Business Can…. Apply Blended Costs to the project and project the overall cost of the project. 01 Validate that Scope and Assumptions matches expectations. 02 Assign Business Value in relation to Costs 03
98. Project Starts
99. Before Issues Arise • Before Sprint Planning Review Detailed Requirements against original complexity estimates. • Communicate differences to Project Manager and Product Owner • Reduce Scope Task Scope, Remove Features, or extend Deadline
100. Stories Keep Slipping From Springs Business is starting to get frustrated by the lack of stories being completed during a Sprint and is coming down on the Project Manager down hard. Project Manager gets frustrated by the developers because everything is 80% done but the needle never moves. A PROJECT STATUS Meeting gets called.
101. How To Prepare • Bring Scope, Out of Scope, and Assumption to the meeting. • Understand how complexity has changed • Estimate what new complexity has done to the original estimate
102. Finger Pointing Begins • Review Requirement • Review In Scope • Review Out of Scope • Review Assumption • Assess What Has Change Since Original Estimate.
103. Agenda • Problems with Estimating • Needs and Wants • Types of Estimation • Opinionated Way To Estimate • Reporting Back to Business • Addressing Issues
104. Questions?