Product Backlog
In the simplest definition, the Scrum Product Backlog is simply a list of all things that need to be done within the project. It replaces the traditional requirements specification artifacts. These items can have a technical nature or can be user-centric e.g. in the form of user stories.
Sprint Backlog
The sprint backlog is a list of tasks identified by the Scrum team to be completed during the Scrum sprint. During the sprint planning meeting, the team selects some number of product backlog items, usually in the form of user stories, and identifies the tasks necessary to complete each user story. The key here is the word TASKS. Usually, the team assigns an estimated point value to the tasks also.
Sprint Goal
A sprint goal is a short, one- or two-sentence, description of what the team plans to achieve during the sprint. It is written collaboratively by the team and the product owner. The following are example sprint goals in an eCommerce application:
- Implement basic shopping cart functionality including add, remove, and update quantities.
- Develop the checkout process: pay for an order, pick shipping, order gift wrapping, etc.
- The sprint goal can be used for quick reporting to those outside the sprint.
- There are always stakeholders who want to know what the team is working on, but who do not need to hear about each product backlog item (user story) in detail. The success of the sprint will later be assessed during the sprint review meeting against the sprint goal, rather than against each specific item selected from the product backlog.
Burn Up Chart
Starting with the layout of the chart, we are in the first quadrant (top right) consisting of a positive X and Y-axis. The X-axis represents the total number of sprints while the Y-axis represents the size of the Product Backlog, usually measured in story points. There is a blue line, a red line, and a green line. The blue line shows the current size of the Product Backlog in story points, the red line shows the sum of story points earned (accepted by the Product Owner in the Product Backlog), and the green line shows the team’s velocity.
This chart is the size of the whole Product Backlog and shows its completion so far, usually updated after each individual sprint. The Product Owner uses the Burn-Up Chart to predict future completion dates and to provide a visual representation of the project’s progress to the Stakeholders.
Burn Down Chart
Again starting with the layout of the chart, we are in the first and possibly fourth quadrant (top right and possibly bottom right) consisting of a positive X-axis and a positive and possibly negative Y-axis (you do not want to be negative). The X-axis represents the number of days for the work to be completed while the Y-axis represents the sum of hours from all tasks in the backlog (usually the case) or it can just be the number of tasks. This chart just has two lines, a blue line and a red line. The blue line shows the planned progress to complete the work on time. The red line shows the work remaining.
This chart represents the backlog, arranged on a daily basis and displays all of the work to complete the backlog. It compares the amount of planned work to the amount of work remaining. The Development Team and the Scrum Master should use this graph because it gives them a visual of their progress and where they stand day by day and if they are on track to complete their work on time.
Product Backlog
This is a list of all of the user stories in one area. Another way you could look at it is all of the sprints combined into one list. The Product Backlog should be seeded with the user stories that were developed during the planning phase of the project. Once seeded, the product backlog may be organized and grouped based on themes of work (similar stories to complete a function). The Product Backlog allows team members to carefully review and track the work that must be completed in order to meet the goals on the roadmap. The Team Members are responsible for completing all of the user stories throughout sprints, but maintaining the Product Backlog is the Product Owner’s responsibility. They should edit, prioritize, and overall keep up with the Product Backlog. The members involved in the creation of the Product Backlog should include some Stakeholders, all Team Members, the Product Owner, and the Scrum Master.
Easy Backlog Example – Project Management Course at Georgia College
Sprint Backlog
At the beginning of every sprint, there is a Sprint Planning meeting where the Scrum Team decides what tasks to complete in the upcoming sprint. The team looks through all of the Product Backlog items that need to be complete and they decide which items they want to include in the current sprint. This collection of Product Backlog items selected for the current sprint is the Sprint Backlog. The Product Backlog is the list of items for the entire project; there is only one of these. Each sprint has its own Sprint Backlog, all of these together make up the entire Product Backlog.
Product Increment
The Product Increment changes after and even during every sprint. It is the sum of all of your completed Product Backlog items once the first item in the first sprint is completed. It is everything you have completed to whatever point you are currently at. It is your existing product, not the final product unless you have completed the project; then the Product Increment is the final product.
The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.”
