We take initiative and ask for forgiveness instead of permission.
Sprint Backlog
Why
The Sprint Backlog contains all of the work that the Development Team has planned to do during this sprint. It is kept up-to-date according to the reality of the sprint, thus providing transparency to all involved.
Prepare for success
Give access to the sprint backlog to all involved: Development Team & Product Owner & key stakeholders. For new customers, someone from Kabisa will explain how the tool works, and what is expected from the various roles within the process.
How
At Kabisa we prefer to use PivotalTracker. It has an easy to use workflow for the Development Team and the Product Owner[1]. The sprint backlog is the “current iteration” in PivotalTracker. The sprint backlog contains the selected user stories and bugs for the sprint. Any specific tasks that have been identified for the stories or bugs are listed as part of them. Also, all general chores that have been identified by the team during Sprint Planning are on the Sprint Backlog.
Definition of Done[2]
At the end of each sprint, the Sprint Backlog should be empty. If not, this needs to be explained at Sprint Review, discussed at the Retrospective, and updated at the next Sprint Planning.
Real Life Example
During the first sprint for the development of a new mobile app, the infrastructure needs to be setup to make the app available for the product owner and some key stakeholders for testing purposes. During Sprint Planning, this is identified by the development team as an important chore to carry out in the first days of the sprint, in order to let the customer test all user stories during the sprint. The team creates the chore on the Sprint Backlog, and puts it above the first User Story[3].