I’ll come straight to the point. I’m not a fan of story points. No, that’s wrong, I’m not a fan of the way story points are used. In my experience, story points are probably one of the most misunderstood and misused tools in all of software development. In fact, not just software development, but all forms of engineering, everywhere.

I have an acquaintance that works in an engineering discipline at a major car manufacturer. They are undergoing an “agile transformation”. Like many organisations, they have brought in external consultants to help them “be agile”. They have set them up with all the tasks and ceremonies required to “do agile”. This has included being told they must use story points. In their case, story points are simultaneously meant to represent 3 unrelated metrics. That’s a lot of pressure to put on a single number. It’s not just story points either, all estimation seems to suffer with these same problems.

The problem, in my experience, is that no one can ever seem to agree on what a story point is. Just like in the above story where story points are being used for 3 unrelated metrics. Compounding this is that everyone tends to be biassed towards what they want story points to be. When a team starts discussing story points there always seems to be people saying they are size, or they are complexity, or value or a combination of any of the above. The one thing everyone seems to agree on is that they most certainly are not time! This is an argument that always confuses me. If we aren’t in some way estimating time, then why do these conversations always end with wanting to use them as a measure for the amount of work we can do?

By now you are probably wondering why am I writing about how to use story points? That’s a good question. Despite how I feel about story points, and estimation in general, I actually frequently recommend teams use them. “Hypocrite!” I hear you cry. The thing is, I recommend teams use them because I also believe they form an important part of a teams journey towards a level of maturity where they can stop using them.

Below I outline my master plan for how you and your team should use story points. The idea is to go on a journey where the end result is that you don’t use story points. If you don’t use story points now, why would you want to go through using them to not use them? Because the end result is a team that better understands its ability to deliver, works together more harmoniously, and better understands the external factors affecting their work.

Story Points vs Duck Points

In order to distinguish between what I was referring to above as story points, and the tool I am going to describe below, I am going to call mine duck points.

What is a Duck Point?

First of all, we need to agree what duck points actually are. This is where I go against the grain a little and say that they are actually a measure of time. However the intention is we start with a measure of time that is as much as possible, intangible. This makes it so that duck points remain ambiguous to time and that their values come naturally.

In order to achieve this when using duck points you should use Fibonacci numbers (starting at 1 through to 21). Then for estimation you can use a tool like planning poker. On the duck point scale 8 is the magic number.

A duck point of 8 is indicative of a task that is of a size and complexity that we would expect a senior engineer in our team would require an entire sprint to complete. Don’t worry if you don’t have a senior engineer, or if you do that they are new to the team and so not a good measure yet. You can use the most senior or efficient member of the team for this yard stick. To clarify, the 8 value relates to all the engineering time the Senior engineer would have free to commit to the ticket in a normal sprint cycle. We should be sure to allow for the fact they have other meetings, commitments and distractions when assessing how much work they can do in a sprint. 

The next part is extremely important. When you first start using duck points, no other numbers should be given a defined value. They will have implied values, less than an 8, a senior engineer could do in less than 1 sprint. Higher than an 8 would take more than 1 sprint. But defining them upfront is forbidden. Over time working through the process, they will begin to define themselves.

One last thing, you can’t assume that you can add them together either. 3 + 5 may or may not equal 8. At the start, this is yet to be known.

How to use Duck Points

Duck points will most naturally fit into three different stages of your process, normally refinement, planning, and review.

Story Refinement

During your refinement session is a great time to use duck points. Once the ticket is refined the final job is to use a planning poker tool and cast your votes on how many duck points the task is. The first few times you do this you will likely have quite varied answers. At this point, get the people who voted highest and lowest to explain why they voted as they did. Sometimes this will result in people changing their minds, others it will result in meeting in a middle ground. Whatever the result, the team should (mostly) agree on a value and assign that to the task. 

Over time you will start to agree more often on the number of duck points for each task. You will start to find outliers will have additional information about why a task is much bigger or smaller than others believed. Getting to the stage where more often than not, there is a near consensus on the value at the initial voting stage is an important milestone on this journey. 

Sprint Planning

The next step can be done in a couple of different ways. Neither is the right way, and you may even come up with your own way. Ultimately, what we need to do is find a way to determine how many tasks we can do in a sprint. To do this you can:

  • Pick an arbitrary number of duck points to bring into a sprint. During the sprint review you would then reflect on what value of duck points were completed and adjust the number for the next sprint up or down as needed. As your estimation improves so will your understanding of how many duck points you can complete in a normal sprint
  • The second option is to do a few sprints in a Kanban style. With tasks living in an ordered backlog and being brought in as and when an engineer has capacity to start a new task. Much like the first option you just review how many duck points were completed in a sprint so that you begin to understand how many the team can complete in one sprint.

There is no defined time for how long you must do this for. It will vary from team to team. What you are looking for is to reach a point where your estimations are closely matched between engineers, and your sprints regularly complete a similar number of duck points. At this stage, things get exciting, we stop estimating in duck points!

How to STOP using Duck Points

This next sprint will feel very strange indeed. At this stage you will be used to using duck points, they will feel as comfortable and normal as any other part of your processes. So now is the time to just stop.

Instead of voting in your next refinement session, you can skip it. Then in the next planning session, you will instead discuss your refined tickets and bring them into the sprint until such a point as the sprint “feels” full. No one person is responsible for declaring the sprint full. In fact I actively encourage all members of the team to call out as soon as they think enough work has been added to the sprint. When that call happens, the team should have a quick discussion to make sure everyone feels they have enough work for the sprint and swap tickets in or out as necessary to make sure everyone is comfortable.

The first few times of doing this you will likely get it wrong and it might be tempting to go back to duck points, but trust the process. Over the next few sprints, just like with duck points, you’ll start to find that common understanding of how much work the team can complete in a sprint without the need for points. Once you’ve reached that point, you have succeeded in using duck points to not need estimation any more.

What if..?

What if the team gets new members and/or people leave?

Of course, teams change, and so repeating this process periodically may prove beneficial. If the team changes significantly. You start to find that you are bringing too much or too little work into a sprint. You feel that your velocity has dropped. There is no shame in that, quite the opposite. Identifying an issue and tackling it head on is something mature, high performing teams do. You may find that you just need a tweak, or that actually your velocity hasn’t dropped, but the work you are doing is more complex and so you are delivering less individual tasks. Or you may find that because of the changes in team structure you do need a full reset. All of that is ok.

What if we prefer to stick with duck / story points?

That’s ok. You don’t even need to defend that position. If you are happy with using them and it works for the team, stick with it. You are the ones there day to day, you do what’s right for you.

Summary

Estimation, whatever form you do it in, can be a very powerful tool for a team to understand how much work you are able to deliver. It can also be a powerful tool to damage a teams morale. The important thing is to make sure that everyone in the team understands what you intend to achieve with estimation and that you all understand what you are actually estimating, and that you don’t keep doing it just “because”. Always be sure to stop when it stops adding value.

I’ve worked in a number of teams where we have followed the “duck points” process above and I’ve always found it to work well. If you try it with your team I would love to hear how it works out for you, so be sure to let me know.

Further reading

If you enjoyed this post, then you might also enjoy my post about Security Testing, or this one about the Zoopla Holistic Testing Model.

Subscribe to The Quality Duck

Did you know you can now subscribe to The Quality Duck? Never miss a post but getting them delivered direct to your mailbox whenever I create a new post. Don’t worry, you won’t get flooded with emails, I post at most once a week.