Struggling with sprint backlogs
Classic SCRUM process defines two types of backlogs.
Product backlog – a list of all features and user stories that are planned to be included in the product.
Sprint backlog – a list of tasks to be completed during the current sprint.
There are a number of important differences between the two. First, there is only one product backlog but there are many sprint backlogs because each has sprint has it’s own. Second, product backlog is usually very “fluid” and open to change (as it should be) while sprint backlogs are extremely static – once defined they are supposed to stay the same. I was lead to believe that changing sprint backlog on the fly can be considered a type of “smell” – in other words an indication of bad practice.
This “duality” is something I have been thinking about lately. Clearly there are some benefits of having static sprint backlog, such as team commitment, “protection” against outside pressures and so on. However the static nature of sprint backlog means that we have to plan all our work a month in advance with good precision (we use month long sprints) and that is something we were unable to do very well even though we are practicing SCRUM for almost a year now.
Perhaps this is specific for our team and project domain but planning a month ahead is always hard for us. We usually have 2 types of user stories: a few “big new feature” ones which are usually very hard to predict correctly and a very large number of “enhancements” which are easy to predict but hard to manage because there are really many of them. Splitting of big user stories into tasks is also rarely possible in advance, but only after we start working a little on them, but because sprint backlog is static we do not bother to update it with smaller tasks.
Because of all of this I have been thinking of replacing static sprint backlogs with more dynamic sprint “queue”. This queue will have a small number of “slots” each filled with a task. Every time a team member completes some task he will be able to pull a new one from the queue (but not from the product backlog). The queue will be refilled once in a while (once a week?) by product owner or scrum master during the daily sync meeting.
I believe this method will really simplify the things. Iteration planning meetings will be shorter and primarily used for high level discussions. Task estimations will be done during queue “refresh” so they will be much more accurate because they will be closer to implementation time. Task and bug management also becomes much simpler because there is no need to plan ahead much. On the other hand we will be able to keep a monthly iteration cycle.
Why not just have a shorter iterations? Well, it is also an option but for us the choice of month long iteration is based on some external factors (such as monthly demo) so I think the backlogs are much easier to change. Other teams may choose differently.
Entry filed under: Agile.