Creating the Sprint Backlog for 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.
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 to break each work item down into individual tasks or cards, each with its own self-contained user story.
Any work items that do not make it into the Sprint Backlog are placed back into the Product Backlog until the team is ready to start the planning process for the next sprint or development iteration.
Not only does the Sprint Backlog define the user stories or individual tasks that will be tackled, it also defines the effort (hours or points) for each user story and creates a plan for delivery. This way, when a card is assigned, the Scrum Master can also estimate the work effort or hours being assigned to each team member and manage the workload accordingly.
For the sprint to be considered complete, each of the tasks must be in a usable/presentable condition and 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
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. 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 GoogleDrive 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 might also 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.
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. 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.
Recommended Further Reading
The following materials may assist you in order to get the most out of this course: