Finally there is a ground setting summary about the #NoEstimates movement and I can highly recommend reading it.
For me the combination of a business novel style (like done in the Phoenix Project, The goal or Five Dysfunctions of a team) – the story about Carmen the project manager – and the explaining fact based surrounding that support Carmens development throughout the book is a great way to tell the story about #NoEstimates.
It took just some hours to read it and helped me a lot to get an even more clear picture why applying #NoEstimates is the way to continue in agile projects.
Some highlights as a teasers for you
The golden rule to determine if something in your organization falls in the category of waste is: “do we want to have more of this? Like double of triple it?
#NoEstimates: estimates do not directly add value to your process … can we find ways to reduce the estimation process or even stop it where possible.
Forecasting … to calculate or predict (some future event or condition) usually as a result of study and analysis of available pertinent data … we use actual data to make calculations instead of using experience and other information to guess at something.
…you don’t want to triple plans, estimates, reports and proposals…
…finally dropped the estimation-based conversations to focus on throughput, cadence and flow…
…#NoEstimates is not about no estimation ever, but about the minimum amount of estimates that will do, and then look carefully at ways to reduce that need even more.
Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.
Parkinson’s Law: Work expands so as to fill the time available for its completion.
Berard’s Law: Walking on water and developing software against a written specification is easy if both are frozen.
Accidential complication (by J.B. Rainsberger): applied to #NoEstimates … you can only determine the real cost of a feature by recognizing and measuring accidental complication or – like I suggest in this book – by using the #NoEstimates approach.
…Work spends considerable more time idle and blocked by system constraints than progressing towards completion… It’s these unknowable system delays that make forecasting software projects exceptionally difficult…
The harming effect when using estimations: internal politics, estimate bargaining, blame shifting, late changes.
…Software does not follow simple causality links. Rather it follows complex causality links. A complex link is for example, when a small change (like a single line) can cause a catastrophic failure… in software, an outlier may completely destroy all the effort that went into creating credible, solid estimates.
Can you predict all the significant changes you will get and the impact of those changes … “building software is like when you try to unclog the pipes in your bathroom and end up to build three more houses just to get the toilet working again”
In software there are many factors affecting performance on the job, and those factors are not predictable nor do they exhibit predictable variation… our intellectual performance is the key determining factor of our productivity and many factors affect us… when you base estimates solely on expert estimation you fail to account for many aspects that affect directly the performance of the project … then you use data from the project to update your forecast, you are factoring in all the aspects of the current project and will be able to detect when the project performance changes.
You need to ask: “given the rate of progress so far, and the amount of work still left, when will the project end?” or similar “given the rate of progress, how much of the work can be finalized by date X?”
Estimates … to give or form a general idea about the value, size or cost of something … are guesses, not facts … as soon as the human mind understands this number it will likely tend to stick to it and give it the category of a fact, in an interesting form of grasping and clinging…
By asking people to reduce their standards or stay over time, you destroy their motivation because of a commitment made based on an estimate.
The start of a project is the worst time to estimate its duration or cost.
…when every task has some specific mini-buffer (padding), Parkinson’s law kicks in and all tasks would expand to consume the available buffer…
…once you know which is the one single most important thing in the universe for your company right now, there is little value in knowing how much is it going to cost when compared to other items in the backlog…
…if you are able to perform this series of strategically critical experiments so quickly, then spending time trying to estimate the length or cost of each experiment is pointless…
…Identifying which features are the ones that deliver most value is therefore more important than finding which of them are small and which are big…
…estimates … cannot give you … visibility to progress and actionable information…
project driven development anti-pattern… other metrics such as quality, product market fit, speed of delivery end up being ignored in favor of being on time and budget.
…make design commitments as late as possible it the project … you have to wait until the last responsible moment; if you move too early, your enemy will spot your movement and neutralize it; but if you wait too much, your opponent will strike you…
heijunka … to reduce variability in the work where possible … by having small user stories … will help you reduce variability in task duration as well as help you identify the unexpected variability early on.
8 possible sources of variability for software teams: technology, domain or product, team composition, user and client, workload and/or focus factor, market and competitors, dependencies and specialization, waiting for availability
- Stabilize your teams and avoid constantly changing people from one team or project to another.
- Define clear priorities, reduce dependencies and allow people to work on one thing at a time, finishing it before starting a new work item
- Build quality into the whole production process, do not try to inspect quality in at the end of the line…ensure that no defects are passed down to the next step in the line
- enforce cross functional groups and generalizing specialist teams
- Standardize and automate where possible
- Protect the team from outside interruptions
- Freeze scope inside iterations and allow the team to work on delivering the most important work without context switching that costs them time and takes focus away from the most important work
- nothing bigger than Big
- sizes in your backlog come randomly (e.g not all small stories in the beginning)
- the statistical distribution of the sizes would be constant and known over time
- verify that the developer has the same understanding as someone else (e.g. Tester, PO)
- ask the end customer if what is implemented really solves the problem that it was intended to solve
- there should be no huge stories (bigger than half a sprint)
- several independent stories should fit into a sprint … six to twelve stories delivered in a 2 week period is a good rule of thumb
- E – essential (instead of estimated) … meaning that every story is absolutely required for the product to be viable
- S – small (instead of specific) … small stories are well understood by the team and can be implemented in a short time frame
- What is the most important value to be delivered by the project from the customer’s perspective?
- What is the amount of work that needs to be completed in number of stories to be delivered?
- When should the next delivery of the project happen?
- What are your intermediary deliveries going to be used for?
- When does the project need to go live with the first release?
- What does the customer expect to accomplish with that first release?
- How many and which RTS do you need to deliver until that first release?
- How many RTS have you successfully delivered during the last 2 months (the length of the project until then)?
- Along functional dependencies
- to separate quick from time intensive functionality
- along user/role separation
- use multiple levels of granularity to establish flexible requirements
- use historical data to assess progress and forecast future delivery
- cost is a multiplier of time; the only real variable the project team can control actively is value (in the form of scope)
- Move to story points
- Stop estimating tasks
- Limit calendar duration of Features and Stories
- If you already are using story points remove some planning poker options
- Build histograms to track average duration for stories and features
- Use average cycle times for stories
- Finally work with stories as if they all had the same duration
UUPS – the teasers list just became a little longer … I hope it inspired you to start reading the book and maybe share your opinions e.g. via a comment or join the discussion under #NoEstimates or #NoEstimatesBook.