In a Nutshell

When right-sizing work we are looking at what size a piece of work needs to be comparative to the vehicle we have to manage that work.

For example, if you are working in 2 week sprints, you want to make sure that the piece of work you are undertaking can be carried out, to our definition of done, within that time. If it can’t then we need to see whether we can break it down further, or remove some of the complexity before we begin. Likewise, if you’re using Kanban and a piece of work is so big and complex it causes it to get blocked, again we can argue that the piece of work was not the right size for the mechanism we are using.

Right-sizing is Important At Every Level:

We can see from the above that we are trying to get items of work to a size which allows our system to run optimally. So far we have talked about work being too big, however, items can also be too small. We could happily be completing tasks all week long but if they are not producing immediate value for the customer then we have fundamentally missed the point.

Right sizing needs to happen at all levels, for example, Initiatives, Epics, Features, User Stories etc. Let’s looks at a few.

User Stories

User stories are a great place to start as these are meant to be the smallest unit of customer value. If we get sizing ‘right’ at this level we are able to accurately work out how long it will take our team to do that piece of work and how quickly we can produce value for the customer.

There are multiple things we can do to understand the right size for an item. Here are 4 must do’s, listed in order:

  • By removing complexity from item and making sure its ‘ready’ before we begin we are on the first step towards right sizing because now we can compare its size against previous stories that we have delivered. We will also then be able to use this story as a predictor of similar sized stories in the future. If you are breaking items down to their smallest level of value you are already half way towards right-sizing.es here

  • Say we are working in 2 weeks sprints we can ask: ‘Compared to stories that have in the past taken us 2 weeks to complete, what do we think the chances of this story also getting to ‘done’ within that time?

  • We can now look at the size of the story and ask what happens when we have tried to take on a story of this size in the past - did it flow through our system or did it cause us problems? We can then take actions to rectify it before it is in the system and can block things up or cause us problems.

  • If we get the above right we can then look back and see how many similar sized piece of work have flowed through our system in the past and therefore track our cadence and hold more meaningful planning sessions.

    For example, after just 10 weeks of working with a particular team a team we worked out that, when they took on 11 similar sized User Stories per Sprint, they felt in control and had time to manage their backlog effectively. Higher than 11 and things started to get stretched. We noticed that preparation for backlog refinement meetings felt rushed, people turned up to the meetings distracted, struggled to concentrate and the board got messy.

Putting all this together, we can say that: if User Stories are a representation of a basic unit of value to the customer, and we know that we can comfortably deliver 11 units of value every 10 days, then we know the sort of level of value we can sustainably produce.

We can see from the above that right-sizing is continuous: during backlog refinement we should be asking whether this item of work represents immediate value for the customer when it is done. We should also be asking what further refinement we could do to ensure that the Story really will be the size we think it will be.

Feature Level:

As with Stories, by looking at our delivery of past Features, we can predict how much time it will take us to deliver a valuable feature. However, because cycle times for features are larger, you might need to look at how many stories traditionally make up a feature. If 22 stories make up a feature and we can comfortably deliver 11 stories every 10 days we get an indication of how quickly we can deliver a valuable feature. Then you can look at what could through our predictions of course. For example, anything that takes 3 months to deliver will most likely cut across some sort of holiday time which may slow down our normal cadence. Also, the larger the feature, the more likely something is going to be more complex than we thought, so we might be wise to build in this into our planning.

Higher levels:

The higher the level, the larger unit of value and therefore the more need to break things down into the smallest possible size. If the unit is so big that the customer is having to wait months before they can see value, you are also waiting for months without the appropriate level of feedback, and therefore the risk of not satisfying the customer’s needs grows considerably, as does the chance of wasted time and effort.

So what is likely to negate your chances of getting right-sizing right?

The chances of getting sizing right all the time are pretty low but of we use the process shown above we improve our odds of success. There are also a number of things that can lower our chances of success. Here are four of the main ones:

  • Dependencies increase the chance of items getting blocked. Stories in particular should be stand alone items that should have had the dependencies removed before they hit the board

  • The more we don’t know about an item the herder it becomes to predict how much effort, time and resource are going to be required in order to reach ‘done’. Check for known unknowns and unknown knowns.

    Known unknows 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 effected over the summer break but we can probably hazard a guess, particularly if we have past data.

    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 and 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 a size are likely to be right.

  • If the team aren’t used to right sizing, or aren’t used to doing it within this particular team, more time is going to be needed during refinement and planning sessions.

  • when we are listen to customer needs we only get so much information – we 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, the more ambiguous the task and the less questions we have asked, the more likely we will make mistakes when it comes to sizing work.

    There are a number of practices that can help right sizing - some of these are shown below - however before using them, we have to understand the discipline of right sizing and the rigour required, hopefully this section covered some of the main things to think about.

Practices:

·       Sizing using Fibonacci sequencing

·       Relative Estimation: Steve Bockman

·       Poker