Thomas Carney on June 14, 2016 #NoEstimates: 6 Software Experts Give Their View on the Movement
In the Agile world, there’s an effort to move away from estimates in hours towards estimating in story points, often using a Fibonacci sequence. The idea is that the larger a story is, the more uncertainty there will be around it and the estimates will be more inaccurate. The approach underscores the uncertainty in every estimate.
But you’re still faced with the problem of how to estimate the specific story points you should assign to adding, for example, face-recognizing photo filters to your app. Is that a handy 3-pointer or a 21-point monster?
Some teams started using Planning Poker to decide on estimates collaboratively. Teams sit around together while the product owner describes a particular story. The team asks questions, and then they all vote on how many points the story should be assigned via simultaneously revealing a number on cards. If they don’t all agree, they kick off the debate again before another round of voting. This can go on until they reach a consensus or they decide that more information is need, so they postpone the decision.
These meetings, the planning poker, the discussions - it all takes time and energy away from working on the product. Doesn’t it distract from the real work of implementing wonderful filters for your photo app?
And so the idea was born that perhaps software teams could reduce or even get rid of estimates all together. The idea was encapsulated in the #NoEstimates hashtag on Twitter.
And let me tell you right now that it caused quite a bit of uproar online.
In fact, talking to the various people involved in the debate, many people were reluctant to talk about it at all!
Twitter wars aside, I’ve gathered insights from various people with different perspectives on #NoEstimates.
Neil Killick on the common ground of #Estimates and #NoEstimates
A simple truth is that the business wants and needs both speed and predictability. Some #NoEstimates critics argue that software practitioners should learn better estimation skills so that our predictability improves. Given that we have to do a lot of estimating as software practitioners, learning and using more effective estimation techniques seems a good idea.
However, in return for #NoEstimates advocates acknowledging that we need to provide estimates for those asking, and get better at doing so, I think it’s time for the critics to acknowledge that arguing that better estimation is the answer to all the dysfunctions surrounding software estimation is another impediment to the debate moving forward.
I see common ground in that we are all trying to create better predictability for our teams, customers and internal stakeholders. If we put aside “better estimation” as a way of doing that, how else might we do it?
Better predictability can be achieved in many other ways: - stability and autonomy of teams; - limited work-in-progress of initiatives (1 per team at any given time); - frequency of delivery of “done” software; - cadence of collaboration – planning, building and reviewing together; - high visibility and transparency of work and progress; and - shared understanding of variability, its effects on long range planning and how/when to try to minimise it or leverage it to our advantage.
To take the NE debate forward, we need to find ways to provide the business with the predictability they need, while at the same time moving away from the dysfunctional behaviours associated with holding teams accountable to estimates in highly unpredictable environments.
We are all trying to create better predictability for our teams, customers and internal stakeholders.
Neil Killick is the Lead Agile Coach @MYOB in Melbourne. He’s a pioneer of #NoEstimates with over 10 years of delivery leadership experience. This is a summary of an article on the topic you can read over at NeilKillick.com
Peter Kretzman Gives the Case Why Estimates Are Important
Business runs on goals and commitments, and on the “best judgment” estimates that help create those goals and commitments. And everyone in the room seems to understand that, except IT.
Let’s dig into the specific reasons why it makes sense to use estimates in business and software development.
Estimates help in project selection over a wider time frame, and they assist in filling in a project portfolio evenly to align with overall team/company capacity. Companies often need to determine which projects to sink time and company resources into.
This is a common and recurring dilemma in every company I’ve ever worked at, where demand for various business functionality always exceeds the supply of resources to fulfill it. In such a ubiquitous scenario, what makes anyone think that the anticipated cost and duration for delivering each potential project should not figure into the decision process that selects the “vital few” from among the many choices?
Estimates reduce overreliance on experimenting with “red herring” projects. Nothing is wrong with selective and judicious experimentation on a small scale, focused on learning and adjusting, but the universal #NoEstimates answer to the project selection conundrum is to “just start”. Well, simply as a practical matter, you can’t “just start” 15 different projects as an experiment and gather enough useful, consistent information on all of them to feed into your decision meaningfully.
There’s simply no way around it: at some point, if you want to choose purposefully among competing options of similar value, you have to take a shot at determining what each project is likely to take (cost, schedule, dependencies), despite imperfect information.
Could this kind of deep discussion happen without producing a “number” (the estimate) as the outcome? Perhaps, but the push to produce (and justify) a specific sizing number tends to facilitate such discussions especially well, and force a degree of sunlight onto the underbellies of issues that might otherwise be ignored.
Estimates force a degree of sunlight onto the underbellies of issues that might otherwise be ignored.
In summary, let’s harken back to common sense once again: given these positive aspects and effects that a rational estimating process can provide, exactly why would anyone state that a desirable goal is “to push forward into limiting estimates, down to zero where possible”?
Peter Kretzman is an information technology and online industry veteran with over 25 years of leadership success across a wide variety of industries and platforms, including wireless, social networking, and enterprise software. You can read more over at PeterKretzman.com. This is an excerpt from Peter Kretzman’s four-part series on the topic.
J. B. Rainsberger: "No, Estimates Are Not Evil"
It’s important not to limit yourself to trying to categorize estimates as entirely good or entirely evil.
I counsel against task-level estimates. I see many groups in the typical enterprise context battling each other over the accuracy of estimates. These fights waste a significant amount of time, energy, and money, and don’t lead particularly well towards improving the situation. Although these groups have some serious problems, they fixate on this one, particular symptom, which they interpret as “inaccurate estimates”.
This fixation not only doesn’t lead to solving the underlying problems, but it also creates problems of its own. The people involved seem blind to how the estimates get in the way, and that’s why I counsel against task-level estimates. I do so in the hope that focusing the group on something else will help them see the underlying problems, get past their petty squabbles over whether the story’s a 20 or a 10 or a 5, and do something aimed at actually improving the situation.
So no, I don’t see the estimates as “the problem”, but rather more mundanely as a pointless distraction. I don’t want to throw estimates away, because good, timely estimates in the hands of mindful practitioners lead to great results; unfortunately, most of the groups that I work with use their estimates to try to settle conflicts that have nothing to do with the estimates at all.
For these groups, estimating well would represent a significantly premature optimization in their process for delivering features. If a group has fundamental problems that manifest as battles over estimates (even though the issues involved have little to do with the estimates themselves), and if those battles distract the group from dealing with the deeper, more fundamental problems, and if the group can improve their situation without estimates, then it seems like a low-risk/high-reward strategy to eliminate the estimates while the group addresses the underlying problems.
J. B. Rainsberger is a consultant, coach, mentor and author who helps both teams and individual programmers learn high-productivity techniques for delivering software. This is a summary of an article at jbrains.ca.
Yuval Yeret's Experience on SAFe With No Estimates
*#NoEstimates* is becoming an alternative to using story points at a team level, particularly for teams using Kanban.
In essence this means not trying to estimate the size of the work; we just make sure we slice work into a size that we can bite on and turn around quickly.
This “No Estimates” inspired approach to story estimation has a couple of benefits: First, it is faster. It also forces teams to slice into smaller stories. Iteration Planning becomes even easier, because you just need to understand your velocity and how many stories you can fit. You spend minimal time estimating.
It’s not without its challenges, however. You might waste time splitting a feature into smaller stories. You might also fail splitting a feature into really small stories. There is also the challenge of how to make rational economic decisions at the Feature/Capability and even Epic level without estimates. #NoEstimates die-hards say it doesn’t make sense to estimate even at this level, not just the stories level.
I’m not convinced. What I typically do in cases where teams stop estimating story sizes is just use story counts as the currency at the higher levels. Something like “This Feature looks similar to other features in the 20-stories range”.
The bottom line: Yuval thinks No Estimates Story Estimation is a legitimate alternative to Story Points Estimation at the SAFe Team Level. But beware of extending the thinking to the Program/Portfolio level.
Yuval Yeret leads consulting services at AgileSparks USA. Their focus is helping organisations looking to improve their agility through Change Management, Training, Implementation and Coaching activities at various phases of the journey. You can read more over at AgileSparks.com. This is an excerpt from Yuval Yeret’s blog post.
Richard Sheridan Reflects on Menlo Innovations & Estimates
We have a very strong estimation practice at Menlo Innovations. We estimate weekly and re-estimate often. I think the reason our team doesn't rebel against the practice, and in fact, embraces it, is that it is a safe practice. We don't punish people if they miss their estimate ... we remind them that it is just that ... an estimate. An estimate is a best guess based on available information. Your guess will often be wrong. That's OK. We learn something by guessing and being wrong. We learn something by guessing and being right. We don't believe we would learn as much if we didn't spend time guessing at all.
An estimate is a best guess based on available information.
We have to explain to our clients that estimates are our best guesses and that we may finish early, or we may go late. As soon as we know we will be late, we share the information since it could affect the planning decision. In other words, if a client values a feature that might take us 4 hours, and once we start the work, we realize the feature will actually take 32 hours, the client may change their mind about the value of the feature and potentially cancel that feature work in favor of something else.
In this way, we keep estimation safe. By keeping it safe, we get better data.
Richard Sheridan, CEO, Chief Storyteller, Author of Joy, Inc. - How We Built a Workplace People Love.
Keith Braithwaite on Estimates in Agile Practice
Most teams doing mainstream Agile development with Scrum-like management practices do far too much estimation to far too little effect. There’s very little to be gained by wrangling over the exact “estimate” for a story, and nothing at all from estimating tasks. Such a team probably shouldn’t even bother to identify or track tasks. Does that mean that they should stop estimating? Not by itself. If a team is using Scrum as its management approach then they are—implicitly or explicitly—optimizing for a certain kind of risk profile, and for certain kinds of visibility and control to go with it and estimation has a place in that story. Can such a team learn to estimate “better”? Yes. Here “better” means “more usefully in less time”. It does not mean “more accurately”. Any claim to or request for accuracy is literally meaningless in the case of story point estimates. If a team is using a Kaban-like management approach—actual Kanban, with strictly enforced WIP limits is pretty rare in my experience—then they are optimizing for a different risk profile and kind of visibility and control and estimation doesn’t have much of a role in that story. Kanban is not better than Scrum, they merely optimize for different things.
Scrum is great for two things: on the one hand, unwedging a development organization which has got stuck in analysis paralysis or in a maze of institutional blockers, and cannot deliver; and on the other hand, bringing visibility and control to a development organization which is lost in chaos and confusion, and cannot deliver. In both cases the larger enterprise paying for that development will, rightly, have little trust in the development organization, and that will be manifested in request for estimates, and even commitments. On the third hand, once Scrum has done its work—high levels of estimation and re-estimation included—and trust is (re)established, the need for Scrum and its administrative overhead—high levels of estimation and re-estimation included—should fade away. Even estimating stories is mainly a transitional practice.
But however the development activity is managed day-to-day, Scrum, Kanban, what-have-you, in almost all for-profit enterprises that make—or, claim to—funding decisions based on expected outlays and returns at some point someone is going to ask: about what order of magnitude of investment should I expect to make in order to build features that I reasonably expect will have about this order of magnitude return? Development organisations need to have a way to answer questions of this nature, if trust is to be retained. There are ways to do that, and it is possible to learn to do them better. Again, “better” means “more usefully for less effort” and not “more accurately”.
An unfortunate source of confusion, which I suspect underlies many of the problems that #NoEstimates is trying to address, is that actual estimates don’t do what many people who ask for them think they do. Those people can also learn to ask better questions. A good test is this: any request for an estimate, especially a big synoptic estimate, should be answered with something like a three point—minimum, expected, maximum—answer. If that shape of answer, never mind the actual numbers, is not acceptable then you’ve learned that you weren’t being asked for an estimate in the first place. You were being asked for something else, and then you can have a useful—but probably difficult—conversation about decision making under uncertainty.
Keith Braithwaite is Director of Customer Solutions at Zuhlke Engineering Ltd. He has developed software and helped others do so for more than 20 years.
Thoughts, stories or experiences regarding the #NoEstimates movement? We'd love to hear them in the comments below.
