Your Product Backlog consists of a prioritised list of all user stories you plan to do.
In Agile projects, teamwork is organised for a maximum of one month, usually two weeks ahead, in the form of Sprints. To plan work for developers during Sprint, we use Sprint Backlog.
Sounds simple enough, doesn’t it?
However, organising and prioritising Sprint Backlog is not a piece of cake and demands some preparations. Thankfully, by introducing best practices, it’s possible to simplify the process and make the best of it.
What’s our advice on how to plant sprint backlog? Let’s get you through it!
Sprint Backlog Organisation: Our Best Practices
What are our best practices concerning Sprint Backlog preparation?
1. Schedule your sprints
First of all, start with a plan. We configure sprints by defining a sprint cadence (set dates). As I already mentioned, sprint cadence lasts between one week to four weeks, no longer. It’s advisable to keep Sprints of the same duration to balance the amount of work and to avoid possible crunches.
2. Set Sprint capacity
By setting team capacity, we determine how estimation of requirements correlates to actual task time. Capacity takes into consideration work hours as well as holidays, vacation days, and non-working days. So, the team knows their deadlines and the exact total number of work hours they have for each sprint.
Azure DevOps, for example, supports us with the capacity tool. As we work day-to-day, we can see:
- if the team is on track,
- who is over, at, or under capacity,
- if tasks are assigned with non-zero remaining work,
- any changes in remaining work,
- how we plan and monitor sprint resources.
3. Prioritise work items in Project Backlog
Rating of work items relates to the business. Now it’s your turn to define your priorities. It helps us arrange the order of priority (at least for few top user stories).
Then, we specify the priority with following values:
- Product cannot ship without it, and it should be done as soon as possible.
- Product cannot ship without it, but it does not need to be done immediately.
- Work item is optional based on resources, time, and risk.
- Work item is not required.
Setting the priorities helps us with organising your Sprint Backlog.
4. Build your Sprint Backlog
First step is to assign work from Product Backlog to Sprint Backlog. Each team member picks the user stories needed to meet your Sprint Goal and adjusts work to fit sprint capacity. We recapitulate each item to make sure everyone understands it in the same way.
Next, we add as many tasks as needed to capture the work required to complete each user story. Tasks are related to different work: design, code, test, content. Usually, each team member adds their own tasks. However, during planning meeting we define the initial tasks.
That’s where Azure DevOps comes in handy, supporting us with its forecasting tool. To use it, we schedule enough future sprints to forecast the entire product backlog and estimate sprint backlog items.
5. Estimate your work items
When we prepare the Sprint Backlog, we provide a relative estimate of the amount of required work. Most Agile methods recommend:
- powers of 2 (1, 2, 4, 8),
- or the Fibonacci sequence (1, 2, 3, 5, 8, etc.).
But, it is still possible to use any numeric unit. At the beginning, during Sprint Planning meeting, we estimate the amount of work required to complete a requirement (at least for few top user stories).
A good rule is to size tasks to take no more than a day to complete. If a task is too large, we break it down.
When work is in progress, we note the amount of work that remains to finish a task and we constantly update this field. We use it to calculate the capacity and the sprint burndown chart.
Finally, when we complete the task, we define the amount of work spent implementing it. Why? To show you the transparency of our work.
6. Use tags
Using tags provides some general guidance of work items type. We also document this guidance in the project wiki.
Tags are used to:
- indicate how tags support queries, filtering, reporting,
- identify cross-team or cross-project dependencies,
- identify milestones of a project.
7. Keep Sprint Backlog tidy
Maintaining order is of key importance. That’s why, by the end of the Sprint, we update the status of items that are fully completed. All work items that remain active or open for that iteration are found and Product Owner takes appropriate action:
- moves them to a different / next iteration,
- returns them to the backlog.
8. Use impediment work item
Impediment work item is a type of work item that helps track unplanned activities which appear during Sprint. Resolving an impediment requires more work beyond what was scheduled. It helps you track and manage these issues until you can resolve and complete them.
Transparency and Order
Thanks to incorporating these practices in our everyday work, every item has a strategic reason for being exactly where it is on the list and it’s much easier to review that list regularly. It also allows us to determine if any new information demands us to reprioritise things.
Most importantly, there’s no room for guessing. By organising all the elements, we make sure that everybody knows exactly what to do. We can also regularly and transparently show you our progress.
