Agile Estimation: Story points, Hours or #noestimate?

How to choose the best estimation unit at an appropriate time. Should it be story points or hours? Or even #noestimates at all? In Agile meetups, we often hear very strong opinions about estimation units. From some perspectives, it even sounds like a religion.

Ways of Estimation

Religion: Story points

Most people express the opinion that hours are dead. „We have story points in agile so let’s use them.“ But once you discuss how they apply story points you will find subgroups here.

The first group understands and applies story points in appropriate ceremonies and in an appropriate way.

The second group understands the story points concept, but it doesn’t apply them at an inappropriate time. And a lot of people use Story points, but for them they just mean man-days.

Religion: Hours are still the best

There are still people who prefer hours. There are different reasons for that. The business model, non-understanding of story points, resistance if the organization, not a big change involved.

Religion: #nostimate, #noprojects,#no?

More and more often we meet guys who do no estimation at all. But even this group is split into those who really do not do any estimation at all, and another group who do not estimate but count the number of finished cards.

So, who is right and who is wrong? Well, the answer is ‚agile‘ in many ways.

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.

Whaaaat?

Let’s start with hours

Be aware that all things we mention here might be false in your case! Talk about the pros and cons with your team and decide together. We do not say that story points can’t be used here or there.

What we do say is that in many cases it might be easier for the team to start the Agile introduction with hours as an estimation unit.

Hours might be the best in the following situations:

1. Legacy product – you are a team without an experience with the legacy product so it is hard for you to compare an effort in story points.
2. You are a vendor/freelancer and you are paid by hours.
3. The team is multidisciplinary for the first time. Different roles have a problem finding common ‚blueberries, the reference backlog items‘.
4. The team is full of experts and it is hard to build up multi-discipline due to the product or technology complexity.
5. You are able to work just in sprints, not release/ program increment iterations regardless of the reasons.

More important than final estimated value is the knowledge sharing within the team. To understand the basis of estimation!

The discussion in the estimation round is a great source of knowledge as estimated tasks are more detailed and easier to be understood by team members. Combine such estimation with breakage of the backlog items into subtasks.

The mistake is not to estimate tasks but calculate the estimation with a focus factor on the mind. A typical indication of this mistake is the question „How many hours our man-day is?“ or a sentence like „Well if our man-day is 6 hours and this is 10 hours task, then that means 1,6 MD.“

Focus factor is used for the Sprint capacity calculation, not for tasks estimation! If you need to spend 1 day on the task, then you will spend 1 day.

We found it very valuable to break down backlog items into tasks and estimate time with every new agile team. We do hours estimation in the Sprint planning sessions only. Not in pre-planning, release planning, or backlog grooming. And, based on the team’s maturity, we try to incorporate story points as soon as possible for the user story level. Story points are for backlog items, hours are for tasks.

Storypoints are the next development stage for your team so you can spend less time in the estimation and more of your life in what you like. In the development and product creation.

Story points here and there

Once you discovered and understood the story points concept, you will want to use them all the time. The benefits are quite nice. The estimation is pretty fast while still accurate. If you know how to do that. Please follow our previous articles (part I, part II) where you can find what the story point is and how to create the catalog of references.

Story points are the best if:

1. Your team understands the concept.
2. You have a references 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 story points. I mean the cost of the development in currency value, not in story points.

In ScrumDesk we use Story points in pre-planning sessions so I, the product owner, know in advance how many user stories I need to prepare. The velocity (the sum of completed story points) is one indicator that I check. It helps me to focus on the topmost important things and prepare them thoroughly.

Story points are a great estimation tool for program increment (release) planning activities. The team doesn’t need to go to the subtasks level which saves a lot of time. We apply As late as a possible principle here.

There are more things you can estimate with story points:

1. The complexity of the problem.
2. The complexity of the solution.
3. An effort is necessary to implement the solution from scratch.
4. An effort is necessary to implement the remaining part of the solution.

While all of them might work (don’t forget, Agile is about the agreements of your team), Mike Cohn (an author of the story points concepts) suggests in his last blog to think about story points as written in the fourth bullet.

In some frameworks, like Scaled Agile Framework, the 1 story point equals 1 man-day. This is because of many teams involved in the complex product development and an alignment of the estimation scales. But that doesn’t mean that you should estimate man-days after the scales are aligned.

TIP: Never estimate time for your user stories!

Even though story points work very well, there is another possible level that you can achieve in faster and more accurate estimation. It is #noestimate.

Darling, there might exist #noestimation at all

Are you building up the business? Can you run it without the numbers? So why you should be positive about the no estimation? Even if you are positive, how?

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

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

Now your ‚software factory‘ produces items of the roughly same size. Like automotive factories producing roughly the same cars. And what you need is to know your throughput – the number of finished items per sprint.

Your velocity is the count of items produced per sprint.

So does #noestimate mean #nonumbers? Hopefully, you got it.

Conclusion

I personally think there is no agile estimation 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.

ScrumMasters should not forget to educate team members, product owners, management, and even the customer. Arrange Question Answers or Lean Coffee sessions to get through the biggest resistance and to find agreements.

I observed evolving Agile teams getting from hours to #noestimate in one year. If they were allowed by the management and if they were still able to provide business performance indicators based on their way of estimation.

So what is your next level? Why do you want to achieve it right now? What are you going to discuss with the team tomorrow?

Read more on estimation

Part I: Agile Estimation: Principles

Part II: Agile Estimation: Real life