Why Affinity Estimation?

Guest post by Max Woolf, software developer at Box UK

Software development practices are improving every hour of every day. Open source software continues to grow exponentially, with companies like GitHub posting explosive growth figures over the past year. Full-stack web frameworks make development quicker and encourage agility more than ever before. However, one aspect of software development remains a thorny subject. Where we still have a lot of work to do: Estimation. With software development being a primarily creative endeavor, why do we put such an emphasis on estimation? We wouldn’t ask a painter or composer to give us an exact completion date because we know it’s impossible! So how is this any different?

Estimation is just part of the game now:  clients expect estimates and we need to be able to provide them to remain competitive. So, why don’t we do it as best we can? Being practitioners of agile methodologies, we’re already past giving estimates in days and hours, but even story-point estimation can be tricky for all but the most experienced teams. We need a better solution and I believe affinity estimation is the next step in improving software estimation for us all.

So, what is affinity estimation?

Affinity estimation is just a technique by which story points are assigned to user stories. It’s not an agile methodology like Scrum, XP or Kanban but it can help improve the planning and estimation elements of agile methodologies like these. It’s also not for everybody! If you belong to an established Scrum team with a steady velocity and high productivity, then maybe changing your estimation technique isn’t a great idea. However, the technique can offer significant benefits for many organizations.

Take a typical Scrum team. Estimation could mean anything from playing planning poker to just sitting around a table and coming to a consensus as a team about the effort required to complete a particular user story. You may find that this creates massive inconsistencies and it takes far too long to nail down a steady velocity since the estimation session takes too many indirect factors into account; things like the mood of the team or subconscious biases can play an important, yet often overlooked, role in user story estimation.

Down to business. There are 3 main parts to a successful affinity estimation session:

1. Backlog grooming and prioritization
2. Relative estimation (sizing)
3. Story-point grouping

Step 1: Backlog grooming and prioritization

As per regular Scrum rules, the product owner needs to prioritize the backlog prior to the estimation meeting.

Step 2: Relative estimation

This is the main task in affinity estimation. Firstly, each user story is written down on a card and placed in a pile. Each member of the development team then takes turns to place a card in a line on the table or adjust the position of a card already on the table.  At the end of this step, there should be a continuous line of user stories from those requiring least effort on the left and those requiring most effort on the right. At this stage, it makes no difference how much more difficult the user stories are from each other. The important thing is that the stories are ordered relative to each other.

Step 3: Story-point grouping

We can now happily say that the user stories on the left are easier than those on the right. Therefore, it’s highly unlikely that the user stories on the left will be 21 story points or the stories on the right will be 1 story point. We also know that if the easier story is 3 points, anything to the right of it must be equal to, or greater than, 3 story points. With this information we can then divide the cards into similarly sized groups and assign a story-point value that can be applied across all user stories in that group.

Does it work?

We certainly think so. Affinity estimation doesn’t solve the problem of assigning story points to user stories, but it does speed up the process considerably. At Box UK, our sprint planning and estimation sessions are much quicker than they were previously with this newly added structure. Our estimation sessions typically take 15-30 minutes less than they did before, and planning sessions can sometimes last under 20 minutes if the backlog has been ordered and all the user stories already estimated.

To speed up the process even further, Box UK has created a tool means we didn’t have to write user stories out on cards and can use a computer instead. It’s in beta at the moment, but we’d love to hear your feedback; take a look at http://estimation.boxuk.com.