One of the key ‘things’ in Agile is ensuring we have a clear shared understanding of requirements. A key part of this is ensuring that the size of a piece of work fits well within a proposed time frame and doesn’t bottle neck our process while we try to get it to ‘done’.

For example, if we are working in 2-week sprints, we want to make sure that the piece of work we are undertaking can be carried out, to our definition of done, comfortably within that time. If it can’t then we need to see whether we can break it down further, or whether we can split the item to remove some of the complexity before we begin.

Likewise, if we are using Kanban and a piece of work is so big and complex it creates a bottleneck in our process, we can argue that the piece of work was not the right size for the workflow we are using.

As well as items being too big, items can also be too small. We could be happily completing tasks all week long but if they are not producing value for the customer then we have fundamentally missed the point.

But is it a fool's errand?

I see a degree of apathy when trying to get people engaged in refining and right-sizing work. ‘Surely, we can’t be too far out with our estimations’, ‘we don’t know enough about the work yet, we will only know how big it is when we get into it’. I have some sympathy when I hear these types of statements as time spent refining and right-sizing feels like it could be waste. The trouble is we humans have a bias for action and a tendency to brush over the complexities that are hidden in the work we are trying to complete.

With just a little bit of up-front effort we can save ourselves a lot of pain a bit later on. All we are trying to do is understand the work and confirm whether the expected value is realisable within the time frame we are planning and without bottlenecking our process. We don’t need to be perfect in our sizing, in fact the 80-20 rule can really come in to its own here: a small bit of effort will get us a long way in ensuring we are not setting ourselves up for a fall. Here are the key considerations to think about:

Small is Beautiful:

Backlog items are typically created when we don’t understand them very well. They will often be large and unstructured. We start refining these backlog items to understand them better, express the value they will create and to move them towards the “right size”. Let’s look at some different sizes of backlog item and think about how we consider the implications of right-sizing.

Nearly-ready backlog items are often expressed as user-stories. These are meant to be small units of customer value. By asking just 3 simple questions, we can better understand a story’s potential size – or at least understand if it’s size might balloon:

1. Where are the potential complexities that could make this story bigger than we expect. For example, are there dependencies attached? Could we end up waiting on others to do their part before we can start or complete the work?

2. When we’ve tried to take on a story of this size in the past, what happened? Did it flow through our process? Did it get blocked? If it was blocked, how can we avoid that happening again?

3. What do we know about this story? Have we done anything like this before or is this very new to us? The more complex the work, the less we can compare it to previous work. The less we know about the work the less likely it is that we can even guess at how long it will take us to deliver its value to the customer.

With much larger and less-refined backlog items we are unable to predict how much time it will take us to deliver value. Particular issues include:

Complexity:

The less we know about a backlog item the harder it becomes to predict how much effort, time and resource are going to be required to achieve ‘done’. Because we lack knowledge, there are likely to be several known-unknowns and unknown-knowns implicit in the item.

Known-unknowns are things we don’t know are going to happen but we can probably predict based on past events. For example, we don’t know if our resource is going to be affected over the summer break but we can probably hazard a guess, particularly if we have past data to refer to.

Unknown-knowns are things we don’t know but others probably do. If other teams have dealt with a similar issue, we may want to ask them about their experience. Similarly, do we know anyone who has worked with our customer before; if so, what did they learn? What about people who have worked on a similar product to us? All this information will enable us to have a better idea as to whether our predictions on size are likely to be right.

Skill and maturity of the team:

If the team aren’t used to refinement and right-sizing, or aren’t used to working together, more effort is going to be needed during refinement and subsequent planning sessions.

Not understanding the customer's needs:

Each time we listen to the customer’s needs we only get so much information – we then tend to fill in any gaps based on our knowledge and understanding of the product, the feature and our customer’s normal preferences. However, the more guessing we do, or the more ambiguous the task, or the less willing the customer is to collaborate and the less questions we have asked, the more likely we will make mistakes when it comes to sizing work.

Use of resources:

There are a number of practices that can help right-sizing: Sustain Product Backlog, Product Backlog Refinement, Defining Customer Needs, Relative Estimation

There are also a number of techniques that can help right sizing: Ideal Days, Story Points and Planning Poker to name but a few. See Relative Estimation for links to some of these.

However before using these, we have to understand the disciplines of refining and right-sizing and the rigour required. Hopefully this article covers some of the main things to think about.