Sprint backlogs are the main artefact in agile software development. The backlog is where all story-cards are listed once they have been defined by product owner and development teams during sprint planning.
It is a powerful concept, which could provide great value for software development projects. There is a common misconception about what software estimation entails. When we break it down, we realise that the only thing we need for effective estimation is an understanding of how much work can be done within a given time frame – and this is something teams still struggle with even though it has been years since Agile was introduced.
Sprint backlogs are a hot topic, but unfortunately a lot of them don’t work for all sorts of reasons. Lots of product owners and teams start out with creating a sprint backlog from day one on the project, but never actually get to do any real prioritisation or selection on tasks before they move into development. For some reason this boosts their feeling that they have chosen the “right” user stories for this sprint, but in reality there is no way to know if it will be done or not when you reach the acceptance testing phase at the end of each sprint cycle.
The expectations on backlogs play a vital role in agile organisations. They act as the link between business, delivery teams and customers who want their requirements implemented quickly. Agile experts claim that this is only possible when product backlog items (PBI) are small enough for one person to handle within 2 weeks, which is usually the default iteration length in most projects.
The top 5 reasons why sprint backlogs don’t work are:
- Your sprint backlog is growing out of control and you don’t know who owns the sprint backlog
- Your Sprint Backlog is not used for all types of work that needs to be done
- You don’t know how many items you can fit into the sprint
- The contents of the sprint may change without affecting the date of delivery (i.e., scope change)
- Team members cannot see why they are working on an item or what it means to “Done”
To fix these problems and to keep your Sprint Backlog under control:
- Create a rolling backlog (and re-align your team)
- Use the sprint as a container for all types of work that needs to be done, not just development
- Know how many items you can fit into the sprint and use this number as a guide when creating new items
- Embrace change and pursue continuous improvement instead of trying to deliver perfect software by any means necessary
- Ensure everyone knows why they are working on each item and what “Done” looks like for it – so they don’t need to ask questions about context.
A way to keep your Sprint Backlog under control is by limiting its size, ideally to 5 – 10 Product Backlog Items/User Stories at a time, though some teams will need more if their velocity is low due to lack of experience. 15-20 is the maximum size any team should ever consider.
If your Sprint Backlog contains items that do not belong there, such as for example mandatory Team tasks, then you need to keep better track of what’s going on in the sprint and why it has been decided to add a user story or a task to it. Keep track of everything in one place! The Sprint Backlog isn’t meant to be an extension of the project management process inside your company, but a tool for working with development teams towards the realization of a product backlog’s items into potentially shippable code by means of iterations or Sprints.
You can use velocity from previous sprint estimates to get an idea of how many story points your team can probably get done in the next sprint.
This is not necessarily true. As you are alluding to, velocity takes into account the number of story points completed during a sprint, but it also includes other influencing factors such as for example holidays periods, sick leaves etc. Also remember that velocity measures the capacity of a team – not its activity. Velocity will give false signals if people are slacking or leave their workstation before they have completed everything that was on their plate at the beginning of the iteration because they’re afraid to go home late and exhausted after another long day at work! It’s better to provide transparency over where everyone stands with regards to their tasks instead of only having an aggregated average value of velocity per team (and yes, this is possible for teams with heterogeneous tasks).
Thus sprint backlogs can be used as a communication tool between stakeholders, project managers and teams to track progress throughout an iteration. You can start out by asking if everyone is on the same page with regards to what has to be done for this sprint. This way you can avoid problems at the beginning of an iteration if some team members are completely clueless about their tasks!
