how and why do we size our backlog?
For teams who don’t size their backlog items or task list. Here are some techniques to assist you in starting this process.
“how and why do we size our backlog?”
It’s an interesting question where there are lots of potential options which can be applied depending on factors such as the number of backlog stories, granularity required and team preference.
Many teams take a simplistic approach and assign a relative size to backlog items by using the T-shirt notation; xs,s,m,l,xl ... You start off by estimating a backlog item which the team has already completed, and assign a retrospective T-Shirt size.
For example: if you had a backlog item to generate a status report and the team estimate it M, then they could conclude that a backlog item to prepare a graph of current support calls would take half that time and assign it a S.
The T-Shirt approach is a simple and effective way of sizing your backlog and doesn’t have the stigma associated to a time comparison that a number based sizing technique does.
Number based techniques can range from days, hours or something more elaborate such as the Fibonacci sequence(0,1, 2, 3, 5, 8, 13, 21, 34, ...)
In the example above given the Fibonacci notation the status report could be estimated at an 8, the graph of current support calls would become a 5. In the Fibonacci series there is no 4, so you would round up not down.
Ok, so we have our sizing technique chosen, what do we do with this information now ?
It can be used for multiple advantage points;
- forecast proposed project phases/end dates
- ensure team members are not being under or over utilised
- resource planning
By assigning backlog items to a set iteration time such as a week or two weeks and assuming you have a consistent team size (no holidays). You are able to retrospectively learn how many backlog items the team can complete by their sizing technique.
For example the team may have completed one 8, two 5 and four 3 items, meaning the optimal backlog items in a given iteration should be around the 30 mark.
From here you can forecast how many iterations are required and adjust the resources accordingly.
Of course there are lots of other factors that come into play here such as team members leaving/joining, unforeseen issues and incomplete backlog that need to be factored in but that is not discussed here.