Guide to Scrum Artifacts
What are Scrum Artifacts?
Artifacts in Scrum methodology can be thought of as pieces of information that are used to outline and guide the development of the product. In practice, the key artifacts that are most commonly used are:
- Product Backlog
- Release Backlog
- Sprint Backlog
- Definition of Done (DoD)
- Product Increment
- Burndown Chart
Each has different data points and information, which we’ll discuss in more detail below.
Product Backlog
A product backlog is a list of everything that needs to be achieved on a project, broken down into individual items. This is where the baseline requirements of every feature needed for the end product are prioritized by the product owner for the Scrum team (more information on Scrum roles here).
It is not a list of unchangeable tasks, but are used as a starting point that often evolves over time. For example, if there is a change in the business environment, marketing conditions, or technical demands, the product backlog will reflect those changes. Product backlogs are often represented using a Scrum board.
The product backlog is usually made up of several different types of items:
- User stories, which are high-level descriptions of a feature, told from the perspective of the end-user of the product.
- Bugs are problems that arise that the product owner wants to be fixed.
- Tasks, which are assigned to the Scrum team to complete.
Through these, the backlog grows as the product is being built. When changes are added, they can include more details, estimates, or a change in priority. The product owner and the team are regularly working on refining the product backlog, which can occur at any time.
Refining the product backlog includes activities such as reviewing the user stories of the highest priority at the top of the backlog, and asking the product owner questions about them. This includes — if necessary — deleting user stories and then writing new ones. This is followed by reprioritizing the product backlog.
Then, these new user stories need to be estimated in terms of their relative size (usually in story points), as compared to other user stories in the backlog. The user stories should be prepared for future releases and sprints, while not losing sight of the big picture of the overarching product architecture as the backlog evolves.
Release Backlog
A release is most frequently associated with a major functionality delivered according to the product roadmap. The release backlog is the list of prioritized user stories from the product backlog that are currently included in the next set of scheduled releases. Depending on the organization’s cadence for releasing functionality, a release may consist of two or more Scrum sprints.
Alternatively, the product owners may also use the roadmap to align with calendar-based releases if an organization uses yearly, half-yearly, quarterly, or monthly releases.
Some organizations may decide to release sprints directly if the organizational governance and compliance framework allows such an operating cadence. Release planning is often used when agile is adopted, but unlike sprint planning, is an optional activity. If an organization does not manage using releases, the sprints will need to be mapped directly to the product roadmap instead.
Sprint Backlog
The sprint backlog is the part of the product backlog that the team will be working on in their sprint. Think of it as the to-do list for the sprint.
The sprint backlog is further broken down into tasks for the team to execute. Every item on the sprint backlog needs to get developed, tested, and documented. The product owner helps the Scrum team come up with a sprint backlog during their sprint meeting.
The sprint backlog is often represented as a task board, which is broken up into columns that represent the workflow. They tend to have the following titles:
- Planned, which are tasks that have yet to start
- In Progress, where the work has begun
- Developed, which are completed tasks that are waiting for verification by another Scrum team member
- Completed, where no more work is required
You may have other steps such as Tested or Verified, depending on your exact Scrum process. Sometimes you will have a simpler task board that has just three statuses: Not Started, In Progress and Done:
The sprint backlog, like the product backlog, is a living document and is changed by the Scrum team. Work is discussed regularly at the daily Scrum and the sprint backlog is modified as needed. This is all happening during the short sprint, and only the Scrum team can make these changes as they occur during the sprint.
Definition of Done (DoD)
The definition of done means that all aspects of a user story have been completed in a sprint backlog. The Scrum team must have a shared idea of what being done means. They should create a definition of done and use this as a checklist as they work on their user stories.
The Scrum team can create their DoD during the first sprint planning. It can then be iterated during their sprint retrospectives. However, that doesn’t mean a DoD is static — it can change dramatically over the course of the project.
Sometimes a team will create a standard DoD template that will be used on all user stories in the project.
Product Increment
The most important Scrum artifact, the product increment is all the product backlog items that have been completed during a sprint. Each sprint is potentially creating shippable product increments, so the product increment must fit into the team’s definition of done and be acceptable to the product owner.
The definition of done is a shared one among the Scrum team, although it is different for each Scrum team. The definition of done evolves as the team matures: it grows more expansive or stringent as the project continues.
The product increment is not only the sum of all the project backlog items completed over the course of a sprint, but it is also the value of the increments over the last number of completed sprints. This is transparency both for the team and for the stakeholders in terms of where the product is at the moment.
Burndown Chart
Progress throughout the sprint is measured by the number of story points left to complete in that sprint and displayed using a ‘burndown chart’. These charts illustrate how quickly the team is working through user stories and tasks (essentially the amount of work left over time).
In addition, during the sprint, you can use a task burndown chart to view the individual Scrum team tasks to get more granular progress reporting.
A story point is an arbitrary measure of the complexity or effort required to implement a user story. The only requirement is that story points are consistently applied. The rate at which story points are completed is called the velocity.
Improve Your Organization of Artifacts with Spira
If you’re looking for a comprehensive solution that can help you keep track of all Scrum artifacts, SpiraTeam is exactly what you need. It gives you easy and intuitive management control of information, as well as reporting dashboards to help inform your every decision. Get started with a free 30-day trial below: