This article looks to discuss ‘Sprint Backlog Creation In Agile Projects’. It provides an introduction to Sprint Backlog and covers Sprint Velocity, Sprint Planning and the Sprint Burndown Chart.
Sprint Backlog Creation
A 59 Seconds Agile Training Video
Sprint Backlog Creation For Product Owners – Part 2
A 59 Seconds Agile Article
Prioritising meeting is held at least once per sprint or as often as needed to keep the backlog in order and not to intrude on day to day sprint delivery too much.
Sprint Backlog Creation: Sprint Velocity
Sprint velocity is the rate at which the team is able to complete tasks. The velocity is measured in the same units as they are estimated (usually points). It is the main factor in deciding on the amount of work the team can commit to for the next sprint as only completed on time tasks count when calculating velocity. As the team, product and overall situation are always changing, then it is reasonable to account for only a subset of more recent sprint velocities when calculating the average velocity.
Sprint velocity is calculated once at the end of the sprint.
Sprint Backlog Creation: Team Availability
Before drawing the line for commitment in the sprint planning meeting, it is crucial to check the team availability for the next sprint. Based on holidays, vacations and other important events, it might be needed to adjust the commitment to match the reduced velocity of the team.
Sprint Backlog Creation: Sprint Planning
Sprint planning meeting is a ceremony of Scrum owned by the Scrum Master. In this meeting, the team goes over the top of the product backlog. These items are estimated in the prioritizing meetings. The team agrees on a delivery plan for the next sprint. Although the product owner is present, this meeting is not about the contents of the stories. It is rather about orchestrating the teams’ resources for delivery. Based on the discussion on how the tasks need to be implemented, tested and delivered the team draws the line and commits to the scope of the sprint, taking into account their historical velocity.
The Sprint planning meeting is usually time-boxed and held once before each sprint starts.
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum:
Sprint burndown
Sprint turndown is an outcome of a sprint. As tasks get completed the burndown chart shows how much work is still to be completed and whether the team is on track or not. If the team is not on track to deliver the sprint as planned, then it is a message to the Scrum Master to find out any obstacles the team might have. This often involves the Product Owner as the obstacles might be user stories that require additional information or decisions. A Product Owner should try to solve these obstacles as quickly as possible and later reflect if and how the issues could have been avoided with better prioritizing and planning prior to the sprint.
Summary
Creating a sprint backlog is a complex process spanning many stakeholders and activities. In order to create a good sprint backlog that delivers maximum value to the users with reasonable effort from the developers. The Scrum team needs to constantly work on improving their velocity and keeping their backlog estimated and relevant to the product vision. For this Scrum provides many different tools like user stories, prioritizing meeting, planning meeting and velocity tracking using the burndown chart.
Prev <— Continue Reading —> Next
The Agile User Stories and Tasks
A 59 Seconds Agile Video Animation
Prev <— Continue Reading —> Next
User Stories Applied
A 59 Seconds Agile Book Review
User Stories Applied by Mike Cohn is one of our favourite books on Agile User Stories. The book starts with an overview into user stories, and details what a user story is and the different aspects of them. He then discusses how to go about writing a user story, and provides details of the INVEST criteria that can be used to determine if the story is meeting all of its objectives. Next Mike gives an in depth discussion of who user stories are written for and where to begin when gathering the details for them. The book then discusses acceptance testing user stories, including how to go about specifying these criteria and the responsibilities of the development team and customers during this process.