Scrum artifacts and what they mean for your project
October 15, 2021
Artifact (noun): something one creates as a result of creative effort, feat, or performance; work by human beings with unique combinations of skills, talents, knowledge, practice, and imagination.
Much in the same way that a novel, a sculpture, or a piece of music is the result of creativity and effort, software development projects (like apps and websites) are creative objects in their own right.
So Scrum artifacts? They’re the different objects resulting from work the development team does during a scrum project. There are three main artifacts, and they play a valuable role in product development.
In this article, we’ll take a closer look at what scrum is, what scrum artifacts are, and how best to manage them. Read on!
A quick intro: What is scrum?
First, a quick summary.
Scrum is a popular agile software development framework that focuses on flexibility, responsiveness to change, and teamwork. It’s a lightweight framework designed to help teams deliver working products quickly and with better quality than traditional frameworks.
Scrum has many underlying principles and practices, and an organization can use it in an almost infinite variety of ways. However, the basic elements remain.
- There must be a single scrum master controlling the process.
- There should be at least one product owner who represents the business/customer perspective.
- The development team should consist of between three to nine developers.
- Daily stand-up meetings happen to check progress and flag any problems early.
Scrum also has some practices that involve how teams should work together. This includes cross-functional team members who have all the necessary skills to complete their tasks and a scrum master who organizes scrum events, removes distractions, and facilitates problem-solving among teams or team members.
What are Agile scrum artifacts?
Agile Scrum artifacts are the final results developers produce after completing a sprint or iteration.
They help make sure that both the scrum team and stakeholders understand where things are in the development process. It also means that if someone wants to check up on things, they can check the scrum’s artifacts (rather than going around asking team members).
In a nutshell: Scrum artifacts give the team and stakeholders insight into how well a sprint performs, including…
- What the team delivers.
- How well the team performs during sprint or iteration.
- The lessons they will apply to future sprints.
- Which tasks need completion to achieve goals.
- How best to organize tasks according to dependencies and priorities.
- How to plan future goals.
The development team generates different artifacts within different stages of the development cycle. All these artifacts must be complete before release day, after which they can modify or update them. Then, they will have help from updates coming in from customers about their learning’s post-launch.
The quality of these will change depending on the stage they’re in. It’s important for teams to actively manage artifact changes through each phase to make sure they can deliver high-quality deliverables when it comes time for release.
The main Agile scrum artifacts
Scrum artifacts fall into these three overarching groups: backlog, sprint backlog, and increments. Here’s what each of these means.
What is a product backlog?
A product backlog is a ranked list of user stories that describe features that are desired by the customer. It also includes bug fixes, work requirements, and other tasks.
Product backlogs include user stories at varying levels of detail, from high-level epics to low-level user stories. Inputs come from a varied mix of sources — from market research to stakeholder requests.
The product backlog is a ‘live’ artifact that’s essentially a flexible list that the product owner can prioritize at any time.
What is a sprint backlog?
A sprint backlog is a prioritized list of tasks for a development team to complete during its next sprint. The sprint backlog includes work for the entire team, including both analysis and design. This includes implementation tasks, which are broken down into user stories.
The team updates the sprint backlog during the sprint planning stage of Scrum. Design and development teams work on smaller sprint activities. If a team does not have the resources to complete all of its tasks, they will remain in the sprint backlog for a subsequent sprint.
A sprint backlog is never complete until the story points in the sprint are achieved through development effort in the sprint. Until then, there may still be incomplete tasks remaining on the board when the sprint ends.
What are product increments?
Product increments are the sum of all the backlog items completed during the sprint, plus all the increments completed in previous sprints.
In order to make sure the scrum team always meets deadlines and completes projects successfully, it’s important to avoid delivering code or functionality until it’s ready for release. Product increments should therefore only contain complete features that underwent testing and run properly. The product increment should answer all three parts of the “Definition of Done” — a checklist that scrum teams should follow during each sprint as they develop their products. It ensures that each sprint delivers value.
What does ‘done’ mean? Well, a feature is complete when the team delivers, tests, and integrates it with other features. Now, it runs correctly and there are no known errors or bugs.
Increments should also include documentation regarding how to use the data and whatever additional information users need to understand it. A complete feature is ready to go to end-users. Or, the team can add it into a product build for testing. This is also considered an increment.
Increments don’t necessarily need to be delivered in their entirety during each sprint. It’s more important that the work done in every sprint adds value and improves the quality of the product than it is for all of the features in an entire release version of the product to be completely finished before showing them off.
How do Increments work with Continuous Delivery/Continuous Integration?
Product increments play an important role in CI/CD in version tracking and version rollback.
An entire build consists of many different pieces and components, each increment is a part of the whole, and all increments together create the full release version. The product owner says which increments go into a particular build and controls what version releases to users at any time.
Teams that integrate their version control with CI/CD tools can use this information to get a better insight into their work progress. They can also keep track of all previous product versions to determine what needs rolling back if an issue arises quickly — as well as reverse-examine commits and link them back to scrum increments.
- Learn more about the continuous delivery pipeline with our guide.
Bonus scrum artifacts: Burndown chart
While not technically an official scrum artifact, burndown charts are used by many development teams to help with tracking progress toward completing all its tasks.
The chart also provides information about whether there are any problems with meeting deadlines for specific days, or if there are extra hours built-in for contingency if things go wrong. The scrum master uses this information to monitor progress.
Agile scrum artifacts are a vital part of the scrum workflow. And the best way to get started is to use a project management tool with scrum artifacts built-in — like Backlog.
Backlog helps you manage scrum artifacts for agile software development teams using Kanban boards, burndown charts, backlogs, and more. It also uses version control tools like GitLab or GitHub to access your project’s code repositories, so it can also display the most recent product increments on its graphs.
Meanwhile, intuitive dashboards present you with the most important information at any time, while custom views let you drill down into individual elements. Viewing changes over time gives you insights into how things change once they are integrated into the system. This, in turn, helps developers find problems that might otherwise be missed until release day while keeping everyone else on the same page — no matter what.