[null, null, {"document_url": "https://www.chrislucian.com/2018/07/software-estimation-paradox.html", "unformatted_src": "https://3.bp.blogspot.com/-bfIoJ9XBPV0/W1dY8p-U7xI/AAAAAAAAceY/SLsqCYUxzEgcunubQiNKeN7YVRbbtm_hQCLcBGAs/s400/HowToPrioritizeSoftwareDevelopment.PNG", "src": "https://3.bp.blogspot.com/-bfIoJ9XBPV0/W1dY8p-U7xI/AAAAAAAAceY/SLsqCYUxzEgcunubQiNKeN7YVRbbtm_hQCLcBGAs/s400/HowToPrioritizeSoftwareDevelopment.PNG", "formatted_filename": "HowToPrioritizeSoftwareDevelopment", "alt_text": "How to prioritize software development without estimates", "rendered_width": 400, "rendered_height": 181}, null, {"document_url": "https://www.chrislucian.com/2018/07/software-estimation-paradox.html", "unformatted_src": "https://2.bp.blogspot.com/-Sl0JIHmxrGU/W1dbdNb-MUI/AAAAAAAAcek/Y0YKSaeI63U4y6HlD9FVSrgbyku0rPWZgCLcBGAs/s400/TheCoreDevelopmentProcess.PNG", "src": "https://2.bp.blogspot.com/-Sl0JIHmxrGU/W1dbdNb-MUI/AAAAAAAAcek/Y0YKSaeI63U4y6HlD9FVSrgbyku0rPWZgCLcBGAs/s400/TheCoreDevelopmentProcess.PNG", "formatted_filename": "TheCoreDevelopmentProcess", "rendered_width": 400, "rendered_height": 328}, null, null, null, null, null, null, null]


Want to be an associate Mobber? Apply Here! Home » Lean » Software Estimation Paradox

Tuesday, July 24, 2018

Software Estimation Paradox


People can estimate well what they have done many times before.

Software developers automate what is repetitive or time consuming.

To estimate something well one must have repeated it many times before and not automated it.

Why would a software developer not automate something repeated many times before?

Does estimation lead to waste?

Given the software estimation paradox we can posit software that can be easily estimated could have been automated. We can also say that software estimation in an environment where estimates turn into deadlines increases the amount of waste produced. This inherently works against core concepts in lean software development.

How do we reduce the waste?

To reduce the waste we should be changing the incentive structure. By incorporating good design, continuous delivery, continuous integration, vertical slices, and prioritizing small features on cost of delay, we can begin to realize value quickly and drastically reduce the waste produced.

What should we do next? If we take all of the features we have to do next. Continuous Delivery and Vertical Slices allow us to pick a feature based on that feature's cost of delay. After selecting the feature, evaluate for any features that contain technology that we have never used before or design choices we do not know. We call these items known unknowns. Note, in a traditional estimation process we would have done an investigation period to be able to estimate these. Once known unknows are found, budget time to produce proof of concepts, or determine that the feature is impossible given our current knowledge. Once all known unknowns are eliminated, work toward deploying the feature until any new unkonwn unknowns are found. If any unknown unknowns are found, once again budget a proof of concept until no unknowns remain. At that point deploy and choose the next feature. Combine this process with the Core Development Process and the code will maintain a high quality and continue forward extracting value along the way. How do we safely implement the reduction in waste?

There are many processes and technologies that support movement in this direction. Slowly incorporate the following practices in this order and gradually you will begin to see a transition.

Have feedback? Join the discussion in the comments! Also Check out the #NoEstimates hashtag on twitter.

 Statements and opinions are my own. Lucian Links Follow @ChristophLucian