choice storypoints hours mandays #noestimate agile estimation scrumHow to choose the best estimation unit in an appropriate time. Should it be storypoints or hours? Or even #noestimates at all?

In Agile meetups, we often hear very strong opinions about estimation units. From some perspective, it even sounds like a religion.

I. Religion: Storypoints

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

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

The second group understands the storypoints concept, but it doesn’t apply them in appropriate time. And a lot of people use Storypoints, but for them they just mean man-days.

II. 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 storypoints, resistance if the organization, not a big change involved.

III. 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 starts 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 storypoints 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 storypoints.
  2. You are vendor/freelancer and you are paid by hours.
  3. The team which is multidisciplinary for the first time. Different roles having a problem to find common ‚blueberries, the reference backlog items‘.
  4. The team full of experts where 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 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 to not to estimate tasks but calculate the estimation with focus factor on the mind. A typical indication of this mistake is the question „How many hours our man-day is?“ or 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 storypoints as soon as possible for user story level. Storypoints 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.

Storypoints here and there

Once you discovered and understood the storypoints 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 storypoint is and how to create the catalog of references.

Storypoints are the best if:

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

In ScrumDesk we use Storypoints 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 storypoints) is one indicator which I check. It helps me to focus on the top most important things and prepare them thoroughly.

Storypoints are great estimation tool for program increment (release) planning activities. The team doesn’t need to go to 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 storypoints:

  1. The complexity of the problem.
  2. The complexity of the solution.
  3. An effort necessary to implement the solution from scratch.
  4. An effort 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 storypoints concepts) suggests in his last blog to think about storypoints as written in the fourth bullet.

In some frameworks, like Scaled Agile Framework, the 1 storypoint equals to 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 storypoints work very well, there is another possible level which 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 you are positive, 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 say 3 days at maximum.

Now your ‚software factory‘ produces items of the roughly same size. Like automotive factory 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 means #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 owner, 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?

 

 

Credits: