Sprint Backlog

Sprint Backlog is a set of tasks chosen to be completed within the current Sprint. In the article about the Product Backlog we wrote about the Release field, which is meant to cut off the list of tasks and put them into a Sprint Backlog.

Initially all the information concerning releases (what goes in which Sprint Backlog) is provided by the Product Owner, but the final decision concerning tasks in Sprints is made by a Development Team.

It’s better to clarify how does a Team decide to put this or that task in Sprint Backlog and how can a Product Owner influence his wishes.

Team performance during Sprint Backlog creation.

A Product Owner can face an unpleasant surprise during the first Team meeting. For example, the number of tasks he was planning to complete within the first Sprint is beyond the Team’s performance limits.

As it is seen in the picture, one task from the first release doesn’t suit. What can a Product Owner do in this situation?

Changing the priorities within Sprint Backlog:

One of the variants is to change the priority rating of the tasks. The most important tasks will be moved to the top of the list and be completed, while the less important tasks will be transferred to the next Sprint. There is a drawback in such a solution – one task will still be not finished.

Changing the workload within Sprint Backlog:

If a Product Owner doesn’t want to change exclude any tasks from a Sprint, he can play with the workload of tasks. Many of them have several add-ons or upgrades and Product Owners usually don’t exclude them. It is possible to exclude these add-ons or upgrades and implement them further on in order to complete all the necessary tasks.

Splitting tasks within Sprint Backlog:

If a Product Owner doesn’t want to reduce the workload of any tasks, it is possible to split a task into two and finish the second part during the second release. Of course not every task can be splitted.