Third post of the Scrum answered series will be dedicated to Sprint Backlog.
Sprint Backlog is only a part of the Product Backlog which we planned to do next Sprint, right?
Not really, Sprint Backlog is much more.
It is not only a list of tasks but also a plan how to execute them to meet the Sprint Goal.
During Sprint Planning you should design your Sprint, taking into consideration things like dependencies between tasks or absences of SMEs and team members. This plan should be detailed for the nearest few days and only drafted for the rest of the Sprint. Why shouldn’t it be detailed for the full sprint right at its beginning? See answer to the next question.
Who is the owner of Sprint Backlog?
It’s the Development Team, no exceptions. During Sprint Planning both Development Team and Product Owner cooperate to shape a Sprint Backlog that would best serve the realization of the Sprint Goal. At the same time, it’s the Development Team who is responsible for defining how the business value expected by the PO will be delivered, and the Sprint Backlog is exactly this ‘how’. Of course, Product Owner has huge impact on the Sprint Backlog – e.g. by setting priorities in Product Backlog, defining Sprint Goal and business needs – but the ownership of this artefact is on the Development Team side.
Can I change the Sprint Backlog?
Yes, and even more – you should change the Sprint Backlog and if you don’t do this, it means that something is wrong. Sprint Backlog should have the same structure as Product Backlog, so more clarity on top of it and less at the bottom. As you progress with the Sprint, new knowledge and experience are being gained by the Development Team.
During each Daily Scrum they should inspect their progress towards the Sprint Goal and adapt as per new findings, which is often reflected directly in the refined, more detailed Sprint Backlog.
If you don’t do that, you reject opportunity to improve. Remember: responding to change is more important than following the plan (see here).
What should be stable during a Sprint is the Sprint Goal, not the Sprint Backlog. Stable Sprint Goal will help you to keep focus on the business value and guide you when changing Sprint Backlog and adjusting a plan for the Sprint.
Should I have tasks related to the Sprint Goal only in the Sprint Backlog?
Up to you. It is helpful and whenever you think of maximizing chances to complete the Sprint Goal, it seems to be a good rule. On the other hand, it is unlikely to be possible in practice. There will always be some bugs, small improvements or work not connected with the Sprint Goal which needs to be done. Putting more tasks non-related to the Sprint Goal into your Sprint Backlog will distract the team and make it way more difficult to focus on achieving it. At some point you’ll realize that the team is not really collaborating, but just dealing with separate topics individually.
The more Sprint Goal related tasks you have, the better focus and shared responsibility within the team.
Product Owner asked us to add something to the Sprint Backlog. What should we do?
In general – it is a Development Team decision to add a new task to the Sprint Backlog. Product Owner can request it but should not force the team to do so. On the other hand, there can exist a clear business reason for adding a new thing to the Sprint Backlog, so the Development Team should not defend themselves for all cost. What is most important is to understand that each such activity increases the risk of not delivering the Sprint Goal and reduces team’s focus.
That’s why you should work with Product Owner to explain this to him or her and cooperate to avoid such situations in the future. Questions that might help you with it:
- Is a new item related to the Sprint Goal?
- Is a new item worth increasing the risk of not delivering the Sprint Goal?
- Is this a must for the current Sprint, or maybe we can plan it for next one? (the shorter Sprints you have, the easier will be to postpone it a while…)
Should you have any other questions about Sprint Backlog, feel free to ask leaving a comment. Next week I will answer questions related to the Sprint itself.