No Estimate agile: is it a good idea or should we just keep estimating time?

A hot topic in Agile right now is the no estimate agile movement. Deciding which estimation unit your team should be using to measure time is one of the biggest challenges Agile teams face.  Should it be hours, story points, or perhaps cumulative flow with no estimates is more your speed?

Estimating Hours

Hours might be the best estimation unit in the following situations:

1. Legacy product – you’re a team without any experience with the legacy product you are working on, so it is hard for you to measure an effort in story points.
2. You are vendor/freelancer and you are paid hourly…
3. The team is full of experts where it is hard to build up multi-discipline due to the complexity of the product or technology.
4. You are only able to work in sprints, not release/ program increment iterations, regardless the reasons.

Most teams transitioning from Waterfall to Agile find this estimation technique comfortable because most Waterfall projects are estimated in time. One cautionary tale about using hours is they are very rarely accurate. Most new and maturing teams lack a definition of ready and a definition of done, and there are continuous arguments over requirement definition that often is not accounted for during the initial planning process.

This churn burns a lot of time during the sprint and leads to story incompletion and a lot of work in progress. Which in turn raises risk and costs your business a loss of revenue.

Story Points: The Gold Standard

Story points are simply an arbitrary measure used by Scrum teams. This is used to measure the effort required to implement a story. In simple terms, it’s a number that tells the team how hard the story is.

Benefits of story points: story points, when done correctly, are the gold standard metric used to define the Scrum team velocity. Most Scrum Teams will use the Fibonacci scale to determine the level of complexity. However, certain teams will use points to define developer days. Either way, story points are a great estimation tool for release planning activities because the team doesn’t need to go down to the subtasks level, which saves a lot of time.

Story points are the best if:

1. Your team understands the concept.
2. You have a reference catalog.
3. You do release planning or sprint pre-planning.
4. Your user stories are real user stories, not just text written as a user story.
5. The team is capable of good discussion on an abstract level.
6. You know how to provide the business metrics based on story points. I mean the cost of the development in currency value, not in story points.

However, most teams new to Scrum struggle with this concept. So how do you effectively use story points? In a recent lunch and learn I taught the team how to story point by tossing objects. I used this exercise by Scrum Alliance.

Let’s face it!  Estimates are difficult no matter what metric you use. When requirements are vague — and it seems that they always are — the best conceivable estimates would also be very vague, making accurate estimation essentially impossible. Even with clear requirements — and it seems that they never are — it is still almost impossible to know how long something will take because we’ve never done it before. If we had done it before, we’d just give it to you. Estimates are often used as a bludgeon to try to get programmers to work faster. This leads to unhappy programmers and to poor software — No one wins. In addition, a focus on estimation often leads to a fascination with completing some fixed scope of work. But the most effective way to do things is to manage scope very carefully, to get the best scope of work accomplished at every point in time. Estimation often militates strongly against doing this. The result:  “Weak Agile” and inferior results.

No estimate agile:  It’s a darn good idea.

Working in a continuous flow, without story estimates, is a great way to work. I think most everyone should try to get there, but how?

Well, it is not so hard at all with these rules:

1. As our velocity, we will just count backlog items we finished.
2. The backlog item’s size in the release will be limited to maximum, let say, 3 days. Including all tasks from the definition of done.
3. Anything bigger will be split from the business, not technology perspective.
4. Research activities or other ‘non-plannable’ activities will be timeboxed to the same length, let’s say 3 days at maximum.

So what’s the right answer? All opinions are correct and wrong at the same time because it depends on the business context, the product, the team, ceremony and maturity with Agile. I personally think there is no agile estimate technique you have to follow. Agile is about adoption so choose the estimation technique based on your goals, problems and the current team’s maturity.

Are you thinking about going agile for your upcoming project but don’t know where to start? Our scrum masters have years of experience running agile projects and can get your team up to speed in no time.

If you would like to schedule a free 15-minute consultation with one of them – simply follow this link, fill out the form, and we will be in touch!