This article looks to discuss what Sprint Backlog items are and who in the Scrum Team is responsible for creating the Sprint Backlog. The article also discusses how to manage the Sprint Backlog Items.
The History of Agile
A 59 Seconds Agile Video Animation
Creating the Sprint Backlog Items with the Scrum Masters
The Sprint Backlog is defined as a group of user stories that are grouped together during the Sprint Planning Meeting. This final grouping represents what the development team believes they can complete during the defined sprint timeframe.
What Does The Sprint Backlog Contain?
The Product Backlog contains a listing of the work items, or epics, that the Product Owner wants to be completed. The Scrum Master will work with the team during the Sprint Planning Meeting. During this meeting they will work together to break down each work item into individual tasks or cards to create a list of tasks. Each of these work items should be its own self-contained user story.
Any work items that do not make it into the Sprint Backlog remain in the Product Backlog. These items remain as a Product Backlog Item until the team is ready to start the planning for the next sprint.
Sprint Backlog Items: Defining the User Stories
The Sprint Backlog defines the user stories and tasks that will be tackled during a Sprint. It also defines the effort (hours or points) for each user story and creates a plan for delivery. When a card is selected for a Sprint (the team selects each work item), the Development Team estimate the work effort or hours. The team members manage their workload accordingly.
For the sprint to be considered complete, each of the tasks must be in a usable/presentable condition. The sprint backlog items should meet the previously defined definition of ‘done’. Any task that is incomplete will either need to be resolved before the sprint can be closed or it will need to be redefined and placed into the next sprint.
Managing the Sprint Backlog Items
Once the sprint has been defined, the Scrum Master and Development Team Lead must now turn their focus to managing the tasks. There are several software options available for this task, however, one of the most comprehensive is Trello. Trello was designed specifically around the principles of Agile.
Sprint Backlog Items: Cross-Functional Teams
As the Agile process has evolved, Trello has grown into an all-inclusive, cross-functional system. With add-on options, teams can connect Evernote, GitHub, Slack and Google Drive to their Trello platform. These connections allow members from a variety of departments to contribute additional information or requested edits during the sprint. Each card may need to move through various groups within the development team. Such as HTML, database or QA or require multiple development steps to achieve the full user story requirement. Trello allows for the creation of checklists. Checklists make it easy to see, at a glance, what has or hasn’t been completed at any point.
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum:
The ability to house all of this information in one place ensures that each card, or task, will become a stand-alone eco-system with all assets, conversations, code, and testing housed within it. At any time, the Scrum Master can look at a card and review its progress, along with any conversations related to that task that has taken place. Trello also has additional features, such as a Burn Down Chart.
Sprint Backlog Items: Burndown Charts
Burn down charts provide an instant snapshot into the current sprint by showing how many hours or points have been consumed as compared to what was allocated for the completion of the full sprint. This is an incredibly useful tool as it will alert a Scrum Master immediately to the possibility of the sprint being danger of not being completed on time.
Having a full picture of each task makes accessing the task’s completion all that much easier. When a sprint rolls into the review process, the reviewers can see the entire picture of what transpired during the course of development. This can often include a change from the original feature due to developmental constraints or an update to the original user story or design.