If you’re estimating, know why you’re estimating
Estimates are lies and estimating is waste. That doesn’t necessarily mean it can’t sometimes be useful. It’s still waste but used at appropriate times, in appropriate ways, and understanding the flaws in the results it can help things along with business and finance people and clients. People just have to realize that it’s just not possible to be any good at estimation. The best you can hope for, and certainly what you should aim for if you have to do it, is consistency rather than accuracy. If you’re always consistently over or consistently under that’s enough for reasonable planning.
A few words on planning generally – don’t get up on the plan, it’s over-rated and will be out-of-date as soon as the wheels hit the road. The act of planning, however, is an important learning exercise. It helps you develop the right reflexes and it’s necessary for identifying high-level goals. Doing the work is about producing the planned goals not following the plan.
Let’s get back to estimation. One person giving estimates is just opinion. And if that person is someone not actually doing the work then, frankly, what the hell do they know! If you’re doing the work and you’re being told to buy into estimates you had no part in making, then you should say no way! When you’re estimating the work you’ll be doing, you’re very likely to be optimistic. We’re all good at underestimating the likelihood of obstacles and focusing on the best case. We even think we can estimate better because we’ve become more familiar with the requirements, the software and the users’ needs over time. Perhaps there’s some small truth in that but there are always unknown unknowns lurking in the dark getting ready to jump out. Even when we start work and we’re learning as we progress we’re still no good at estimating how much work is remaining. We’re great at knowing when something isn’t started and we’re ok at knowing when something is actually finished, but we’re bloody rubbish at anything in between.
Using range estimations
People have asked how Energized Work is using estimates nowadays, if at all. Well, currently, we don’t work hard at estimation but we have found it useful in two regards – forecasting and reducing variation to achieve smoother flow. Being ever conscious of waste, we have reduced and continue to reduce the waste within the estimation mechanisms we use so that we get the benefit for the least overhead.
We only use range estimates. A single point in time estimate – “the functionality specified will take 64 man-days and will cost £126,396” – is pants and feeds the illusion of accuracy. Management and clients probably already think an estimate is a promise to deliver so don’t give them the impression of accuracy. A range estimate – “that can be done in 1 to 2 elapsed days” – conveys the amount of uncertainty inherently present to management and clients, whether they like it or not, and sets their expectations more realistically.
An aid to forecasting
These days our backlog is a story mind-map that identifies the user activities (e.g. play football) and the constituent high-level user tasks (e.g. pass the ball, tackle a player, take a penalty, throw the ball in, take a corner). We use this level of scope detail for forecasting, which is linked to incremental funding from our clients based on a quarterly charter. Stories on the mind-map are quickly estimated using t-shirt sizes for ease of language. Each t-shirt has an elapsed day range from the least time it would take to complete the story to the most time it would take.
The least estimates are added and the most estimates are added. Together they create a total range estimate – “somewhere within this range of time and this range of cost, up to but not exceeding the budget, we can deliver something within this range of functionality”. The odds of getting ‘on the green’ (or in the box) are way better that ‘hitting a hole in one’ (or hitting a specific date). Providing a range has always been good enough and acceptable for forecasting and budgeting purposes.
Reducing variation and smoothing the flow
In 2007, Jeff Patton reminded us all that it’s not iteration if we only do it once. As a means to vary scope effectively, deal with uncertainty and still hit the deadline, he prompted us to iterate the functional depth of features and prioritize features by necessity, flexibility, safety, and finally by comfort, luxury and performance. We’ve been working this way ever since.
When a space on the Kanban board triggers an on-demand planning Pomodoro, we huddle around the mind-map, identify the user activity to invest in, write a physical story card for the prioritized high-level user task and discuss an acceptable level of functional depth to build for validation by users. Only at this point, does a high-level user task such as ‘take a penalty’ become something more specific like ‘blast the ball into the top right corner from a short run up’. Knowing when the acceptance criteria on the back of the card have captured enough detail and whether the story is about the right size drives the amount of discussion. The story card is then placed on the Kanban board.
Right-sizing stories reduces variation, which helps us achieve a smoother flow and a more predictable cycle time.
It also allows us to simply count the number of cards to determine throughput, work-in-process, inventory and calculate an indicative cost per card that gives us financial figures for the cost of inventory, rework, etc.
The right size story for us is about 2 elapsed days, on average. Small is beautiful in so many ways – complexity is reduced, the regular sense of completion is a nice feeling to experience, and actually, we don’t have to over-process to achieve functionally coherent stories this size because we’ve actually become really good at it over the years. We ditched planning poker a long time ago. It was always effective but took longer than was necessary. Now we simply ask can the story be done in 2 days or less? If everyone answers yes, then we’re done. Otherwise we talk a bit more and agree how to reduce the scope a little, then we ask the question again.
This is working well for us currently. It has really helped us to have just enough discussion to make a start, deferring more discussion to later. But I’m curious to see what happens when we stop asking whether stories can be done in 2 days or less. I wonder if the average story size will remain the same? Is it a collective instinct that drives enough discussion to happen so that we arrive at a story that is approximately 2 days or less to complete? Or is it simply answering no to the question? I wonder.