Is there a right size for “rightsizing”?
All work at the top of the backlog needs to be the right size for the team to start work. If “backlog” represents fuel for the fire, this is breaking logs down into kindling. Assuming we work in iterations, work should be broken down small enough to be confident of finishing in an iteration.
Why does this matter?
We plan work for an iteration and aim to complete the work that we have planned. Work which takes longer than an iteration can of course never be completed in the iteration. Even work which is smaller than an iteration in size may still be a problem.
Imagine we have a ten day iteration and our backlog items take six elapsed days. We complete one. This uses sixty percent of our iteration. We then start the next one. Because it take six elapsed days and the iteration is only ten days, it is in progress at the end. So the iteration ends with only six of the ten days resulting in completed work and large amounts of incomplete work.
Whenever the duration of backlog items approaches the iteration duration, we tend to have a problem from incomplete work. Any incomplete work item becomes a significant fraction of the whole iteration. This means that less work is shippable at the end of the iteration and more is carried over to the next iteration.
With larger backlog items and more work carried over, we find it harder to get stable velocity. Velocity will vary according to whether individual items are “just finished” or “just not finished”. There is also a risk that the teams will perceive a pressure to complete work items, potentially modifiying the Definition of Done and affecting quality.
What size is “right”?
In general we should aim for refinement to reduce work items to below half an iteration in schedule days to complete. Ideally a quarter of an iteration would be a good target.
If we use a ten day Sprint that would mean backlog items of 3 days or less. For a one week (5 day) Sprint it would be 1 day or less. This work decomposition is one area which makes the smaller Sprint sizes more of a challenge for inexperienced teams.
Breaking backlog items down is often called “rightsizing”. The value of rightsizing to make work ready to be started is clear.
Rightsizing has one extra benefit. The more you rightsize work, the less critical estimation becomes as a tool. If work items are similar in size, you can track progress by simply counting work items. Many Lean metrics focus on assumed-identical items. In a fully rightsized system you could count items and look at how fast they are produced. This can become a tracking metric as effective as velocity.
Good practices
As an Agile leader, look at the work that teams are pulling into iterations after Sprint Planning.
Before the team starts an iteration they need the work to be small enough to fit in the iteration. Ideally well below half the size of the iteration.
Discuss with the teams why small batch sizes are important and some of the key parameters:
- The spread of sizes of backlog items and cycle time for work
- The number partially complete at the end of the Sprint
- The shape of the burndown chart, for example how long before items start being closed.
We can measure how long things take, in “cycle time”, and use that to make such predictions as are necessary.
Ron Jeffreys
Leave a Reply