Going Beyond Lean and Agile: Introducing FLEX – FLow for Enterprise Transformation (online book)
Table of Contents
Introduction to FLEX
Part I: Understanding what is required for flow in your organization (with exercises)
Part II: Using FLEX to transform your organization (with exercises)
Part III: Topics In Depth- Value Stream Wide
Part IV: Topics in Depth - Practices
Part V: Topics in Depth - Teaching and Adoption
Part VI: Using FLEX to both enhance and simplify SAFe
Part VII: Additional Resources on the Net Objectives Portal
Estimation has both advantages and risks to it. They can be used badly or well. Here are the purposes of estimates.
The dangers of estimation occur when they are done in hours or, when done in story points, management doesn’t understand the purpose of using velocity. Estimates in hours are virtually always ineffective unless the development team has fully tested code that has automated tests and uses test-first methods at both the acceptance and unit test level.
You can only estimate well on what you know or when you have a sense of what you don’t know. In other words, if you think something is going to take three days but also know your requirements are not quite clear, you might reasonably estimate it to take four days. But is not always enough. There can be other factors that influence how long it will take to get a new feature done. Here are some examples.
These factors are “unknown unknowns” and unknown unknowns significantly impact estimates. Often, you can do a good job estimating what you know. You can even do poor estimates on what you don’t know (when you now you don’t know it!). But you cannot possibly estimate what we don’t know when you don’t know you don’t know it. (Think about it.)
This leads to a new opportunity for estimating. If you think something should take three days and it took five, your first question should be, “Why was that? Why were we wrong about the estimate?” Ask it as a true inquiry. Is it that you can’t estimate? Or is it that you are making assumptions about what you don’t know without it? If you see “bad” estimates as a reflection of the “gotchas” in your requirements and code, you can use their poorness as an indicator of failures in your process and an indicator of code quality.
If this is true, then improving your process can lead to better estimates. One approach is to use Behavior-Driven Development with Given-When-Then as a way to write the specifications; this creates greater clarity on the requirements. Another approach is to use automated testing (even at the functional level); this helps developers fix their bugs much quicker.
Turn your thinking around. Poor estimates don’t mean you have poor developers. They reflect poor process and code quality. Use poor estimates to provide motivation to invest in a better workflow, automating tests, and reducing technical debt.