Sometimes you come across a subject that peak your interest (in a good way). This week I stumbled across the subject of no estimates. This great tweet by Vasco Duarte really pulled me right in.
After reading some blogs and watching some talks, it really made me wonder. Why do all the teams I work with estimate stories? And the only reason I can think of is that they teach it in Scrum 101, and how would you ever be able to predict when a project would finish? No Estimates provides a way to take a different approach. What is that approach? Let's dive right in!
What is no estimates?
One of the agile principles is to respond to change over following a plan. But in reality, how many times have you been in a longer project, where you were asked to estimate all stories so Management or a Product owner would get a good grasp on how long a project would take? While the first stories you would actually work on might have a semi-accurate estimation, but how accurate are your estimates really for stories that you will not pick up for another 2 months, with all kinds of lessons learned before you get there?
The idea with no estimates is to stop estimating your stories. At first, this thought had me a bit skeptical. How can this possibly work? How can we possibly be on a steady pace if we don't somehow can point that an "8 story pointer" is much more complicated than just a 1 story point ticket?
No Estimates in practice
In this great talk by Allen Holub, he shares how he tackles to use it in practice.
The approach they take is to count the stories. Make sure your stories are small enough and give them 1 story point as an estimation. This might feel contradicting, but the data shows this is more accurate than using the Fibonacci sequence for estimating.
This means you no longer have to spend time as a team to estimate stories, that end up being wrong in the end. The way you calculate velocity can still be used in the same way.
Obstacles to overcome
The reason estimates exist in the first place is because estimating in time was not accurate but usually, people in the business need it for their planning. No Estimates can feel a bit controversial, and managers can panic if they no longer have the influence on their planning.
If you are lucky enough to have Management that is willing to listen to the positives, go ahead! If you are unlucky, you might need to pitch the idea more often, or maybe put on your bad-ass hat, and just go for an experiment of a couple of sprints and present the results afterward.
Conclusion
No estimates are a great way to reduce time spent in planning. Estimations are often wrong and very hard to get accurate. So why not eliminate the need for them? No Estimates offers a good alternative for estimations. Try to get a more accurate picture of work, and not use a method that is known to be less effective.
The concept might seem radical or idealogic to some people, and one of the downsides is that Managers with control tendencies will likely be difficult to convince to give this a try.
If you are interested in reading more of my content, I can recommend checking The importance of off-screen hobbies.
Top comments (10)
Before an of that, I would first clarify: what is the purpose of estimations? The great downside IMHO is that they invariably enable management to press for "when is it done" (project, task, story).
If you observe Scrum 101, aside from no mention of stories, it's that plannings are meant to clarify how much the team can do, not when is it done. It might be done at the end of the Sprint. That's that.
If we estimate, we estimate to be able to say how much we can do.
Most people have never read Steve McConnell's book "Software Estimation: Demystifying the Black Art" and aren't familiar with useful methods of estimation (like PERT). So their estimates are not estimates at all. Just SWAGs (stupid wild awful guesses).
With a good estimation approach, estimates are useful.
I have some experience in both.
In my last team we estimated story points, tasks, and task hours. (The latter two were frequently inaccurate.) We entered worked hours daily. Every day reminded me of the time pressure. The pro is: I stayed more focused and got more stories done. I didn't get too distracted with "gold plating" my features, or if I did it was on my own time. But the time pressure also meant more shortcuts (technical debt) and reduced business impact. By reduced business impact, I mean sometimes the work technically fulfills the story but doesn't quite please the stakeholder. Which may result in another story.
In my current team, we started out doing estimation similarly. We eventually stopped tracking/estimating hours, then stopped estimating tasks. Devs can use tasks however they like on their stories. I still try to estimate stories with t-shirt sizes -- small, medium, large. We only put 1 large story per person in a sprint. We also do design sessions for many/most stories. The pros and cons are pretty much inverted from the previous team. We work with stakeholders to make sure stories match their expectations. We fix bugs right away. We address important systemic issues. But we can't be sure when a specific story will be done. Large stories can end up spanning multiple sprints. I mainly report stories in progress to my boss. Sometimes milestone progress and next stories in queue. But I get pretty uncomfortable when asked for estimates or timeframes, and just give my best guess.
Having said all that, these two situations are apples-to-oranges. My last team was working on an old internal system. The broad strokes of functionality were well established long ago. Many of the backlog stories were increments and refinements. The estimates were still inaccurate and irritating. (Because time pressure also discouraged doing enough design for closer estimates.) We got into a regular cycle of alternating between over- and under-estimating. But this "feature factory" approach worked well enough. I had a great team and manager, so I was content overall.
In the current team, we are building a collaborative product while learning new tech and patterns. (It's actually worse than that -- a cloud redesign of an existing product. The MVP scope was giant.) New features can affect multiple personas/apps and have major interactions with previous features. Sometimes a feature isn't useful in smaller pieces. It is developed end-to-end by one person. Front, back, database, everything. So yeah it can span more than one sprint. When we did task/hour estimates and burndown, they just created busy work with continually changing them to match reality. Especially at the start when so much is being discovered. Note that we have released 2 products under this scheme.
Oh it would be lovely if this practice gains more traction especially to management types, because most development work has a lot of unknowns. I'm not super experienced yet, but I haven't seen estimations of when stuff will be done that actually helped, only caused stress really. Andrei is spot on with the reminder. Even in Scrum, the estimation is supposed to be for how much the team can do :)
How do you know the size of the story without estimating its size?
Note: story points are a size estimate, not a time estimate.
Conversely how do you know how large a story is if you don't know how long it will take? Is it really a large story if it only takes an hour? What are the quantifiers of a story's size?
Just things to think about. I personally don't think any form of estimating, whether size or time, is productive to the developer and the end goal of producing value to the customer/business.
The size is about discussion. It could be a large story if it takes an hour and you thought it would take weeks. It could be that you didn't know how long it would take. It could be that the expectation was a junior dev would be working on it.
Everyone on the team is then supposed to hear why dev one and dev 2 are in disagreement. At the end of the day it gives an idea of what you'll complete in a sprint.
The challenge has always been that these story estimates are supported to be an estimate, quick, and revisited. Are you adding some estimates to stories in the next sprint, throw in some numbers and update when sprint planning. But management gets their expectations that these are deadlines instead.
I agree discussion is important. The heart of any developer team is communication, and more specifically effective communication.
The problem with that estimate of "takes an hour and you thought it would take weeks" is it doesn't effectively communicate nor help plan what you will get done in a sprint to an extent. Obviously a person could say "i'll get this one story done in this two week sprint" where the story is adding a dropdown to a form. They end up getting it done in a day and have nearly two weeks of work left open. Of course they can pull things in to stay productive, but now it is unplanned territory.
Ultimately I think there are too many variables to effectively estimate. Sleep, home life, complexity of work, pto, who is working on it, who needs to talk to who, weather (too hot/too cold), noise, health, etc. All of these can have a significant effect on how long a task takes to finish and can change at any time. Some of them change day to day. To use an analogy of throwing a ball, does it help someone catch the ball if you tell them "the ball will be somewhere between me dropping it and throwing it as hard as I can"? I am of the opinion that it does not.
I think that a lot of misconception comes from, non-technical people will have absolutely no basis for how difficult something will be. Granted story points are intended to be used by the development team.
As for all those realities setting in, it is supposed to prompt discussions on what is at risk in the sprint.
As for taking one story into a sprint, we can reach for kanban style in that case.
I've always considered estimates to be a total waste of time. I just won't do it