As you build your Scrum toolkit, there are a few fundamental elements that are helpful for you and your team to understand on the path to developing an effective Scrum discipline. Scrum artifacts are the basic building blocks that allow you to plan, organize, and track the progress of your work.
I’ll walk you through all the components you might utilize within the Scrum framework.
Product Backlog
The product backlog provides a shared “source of truth” as it pertains to the vision for the product. It’s a whole-product wish list, ordered by business value.
The product backlog contains three types of product backlog items:
- User stories – items that provide direct value to the product owner and, by extension, business stakeholders (read more about writing user stories).
- Bugs – defects the product owner would like to have fixed.
- Tasks – items the development team would like to complete that provide value to them and provide indirect value to business stakeholders.
Only the product owner may modify the product backlog, though items may be added to the product backlog by other individuals with the product owner’s permission. It’s up to the product owner to distill the wants, needs, and desires of all business stakeholders—including internal stakeholders and customers—to ensure the product backlog contains the appropriate items and is ordered by highest business value.
The entire Scrum team works collaboratively to assist the product owner with the product backlog, ensuring product backlog items have the appropriate level of detail to allow members of the development team to understand what needs to be done.
The user stories on the product backlog are estimated by the development team, allowing business stakeholders to understand the relative size of each. We use planning poker as our chosen method for planning and estimating.
This process of refining the product backlog to add details, ensuring the appropriate order, and adding estimates continues throughout the lifetime of the project. The development team spends up to 10% of their time each sprint working with the product owner on refining the product backlog.
Sprint Backlog
The sprint backlog contains the product backlog items the development team commits to completing as part of the upcoming sprint. It includes a breakdown of the specific subtasks required to complete each item and a time estimate in hours for each subtask.
The development team forms the sprint backlog during their sprint planning ceremony, which is when the team creates a detailed plan for how they will complete the high-priority product backlog items they are committing to in a sprint.
The sprint backlog is represented visually by a sprint task board, which presents the product backlog items with their subtasks. As the team completes work, subtasks move through a series of phases represented by columns on the sprint task board.
We find the following columns to be the most helpful on our sprint task boards:
- To Do – includes subtasks that have not yet been started.
- In Progress – includes subtasks where some work has been started.
- To Verify – includes subtasks that have been completed and are awaiting verification by another Scrum team member.
- Done – includes subtasks which do not require any remaining work.
Each subtask includes an estimate of the remaining hours required to drive it to done, including any time required to verify the work. As work progresses on a subtask, the remaining time is updated by the development team based on their current estimate of what’s left to drive it to done.
Note that the remaining time may not be equal to the original estimate less any time spent working on the subtask, as the original estimate may have been either too high or too low. All that matters is the current estimate is as accurate as it can be concerning the development team’s current understanding of the remaining work.
Sprint Burndown Chart
It’s helpful for a development team to have an accurate way to measure their progress during a sprint. The sprint burndown chart provides a graphical representation of the progress of the sprint. It’s measured by plotting the total number of hours of work remaining to complete the open subtasks in the sprint at any particular point in time. By reviewing the chart each day, the development team can see how they’re “burning down” the work as they get closer and closer to the end of the sprint.
A tool such as JIRA can generate the sprint burndown chart like the one above, or one can be created in a software application such as Microsoft Excel. The development team reviews the sprint burndown chart during the daily stand up to monitor their progress.
You can typically understand the status of the sprint by looking at the current hours remaining as compared to a “best-fit” line representing an equal number of hours completed each day of the sprint.
- If the total hours are tracking with the line, that means the sprint is on track, and the development team is on their way to successfully delivering on their commitment to the product owner.
- If the total hours are below the line, the development team is ahead of the game, and if things continue along the way they’ve been going, they may be able to pull in additional work toward the end of the sprint.
- If the total hours are above the line, the development team is behind and needs to make a course correction to get back on track.
The sprint burndown chart is the “health meter” of the sprint.
Release Burndown Chart
Similar to the sprint burndown, the release burndown shows progress over time. In this case, instead of showing progress for a single sprint, the release burndown summarizes progress across multiple sprints and predicts a completion timeframe based on two pieces of information:
- The total story points in incomplete user stories identified for the next release
- The average velocity of the Scrum team
For each sprint, the chart shows the total story points the Scrum team completes, the total story points that remain, and the total story points of any scope that the team adds during the sprint. This one chart summarizes the critical information to understand the big picture of a particular release.
Potentially Shippable Product Increment
The work driven to done by the development team during each sprint is a “potentially shippable” product increment, including work that the product owner has reviewed and accepted on behalf of the stakeholders they represent.
Shippable means the work that is complete meets the definition of done and is ready to be put into end user’s hands. Said another way, the product is at a usable state of quality, and no additional changes are required.
Potentially shippable means that, although the product is at an appropriate level of quality to be usable, it may not be something the product owner decides to release. For example, the product owner may decide that additional enhancements are required, or there may be some incomplete stories that are important before the product is released.
The definition of done ensures that the Scrum team and stakeholders all understand what is required to call a story “done.”
This emphasis on the increment being potentially shippable at the end of each sprint is an indispensable way to ensure everyone understands the state of the product. If the product owner accepts a feature that doesn’t really work, or there are still some open bugs, it would be difficult for stakeholders to understand the actual progress of the product.
By enforcing the rule that the increment needs to be potentially shippable—with the product owner acting as the gatekeeper—it helps everyone understand precisely the current state of the product.
Once you and your team have a firm grasp on how to best leverage the essential ingredients of Scrum, read more about Scrum Ceremonies to make your next sprint really cook!
Read my post about Writing User Stories to get started on building your product backlog.
