Agile Scrum Artifacts 101

If you’ve ever heard about Agile methodology or Scrum framework (that is a part of Agile), then you probably also heard about the Scrum artifacts.

Some people call them Agile Scrum artifacts. Others just say Scrum artifacts. The terms are used interchangeably, so if you see us using both, just know that we are referring to the same thing.

Scrum artifacts are those magic helpers that assist Scrum teams and project managers with delivering the best product they can. A lot of people swear by them, but what exactly are they?

Today we will explore the concept of Scrum artifacts in detail, find out what exactly they do and how they fit into the Scrum process. So, if you are interested, continue reading!

What does the Scrum Artifact mean?

Agile Scrum artifacts are elements of the Scrum framework that support and help Scrum teams with their software development journey. The artifacts provide structure and allow development teams to stay on track with the project and meet market demands. Understanding the demands of the market will also help to cooperate with a startup marketing agency.

The key by-the-book artifacts that we will look at today are product backlog, sprint backlog, and product increment.

Because Agile and Scrum are highly flexible and adaptable concepts, they are often mutating under certain teams’ and companies’ influence. As a result, many terms and processes shift and change. It is the same with Scrum artifacts which are sometimes extended to include non-classical options, such as:

• Burnup chart
• Burndown chart
• Sprint plan

How do the Scrum artifacts help the teams?

Scrum artifacts help agile teams stay focused on their main goals.

Because Scrum teams are cross-functional and self-organization is emphasized, using online planning, whereas control and management are heavily toned down, they need that extra boost and structure to keep them on the right path.

Projects tend to derail from the original plan, even if everything is clearly planned out in the best schedule maker. Internal or external events (who on Earth could have foreseen a pandemic?) cause uncertainty and the need for change. And then there is the always present hectic atmosphere, so typical during software development. No surprise that a Scrum team can feel lost or lose track of what’s important.

Scrum artifacts allow teams to spot those changes and shift and stay true to their goals and plans. Each focuses on a specific aspect of the Scrum project and helps teams narrow down their focus by breaking the huge chunk of work into smaller, manageable bits in their daily planner online. Daily planning in the schedule calendar planner is generally very recommendable because it helps to keep everything under control.

Product backlog, sprint backlog, and product increment are basically transit hubs where teams get to meet, catch up, discuss what’s going on, and work through the issues or opportunities together.

The alternative use of artifacts is for stakeholders to check them when wanting a project update. Rather than reaching out to the development team or the product owner, stakeholders check the artifacts to find any information they’re after.

The 3 Scrum artifacts

Now that we’ve learnt the basic idea behind the Scrum artifacts, let’s look into each one in more detail.

#1 Product backlog

Product backlog focuses on the future of the team: what will the team be working on during the next sprints?

The product backlog is a list of all items for the project. It includes every feature, functionality, enhancement tweaks, bugs to be fixed, add-ons, adjustments. Literally, anything that the team will be working on throughout the sprints.

The majority of the input for the product backlog comes from the client, but some of it is also contributed by the team. The development team is in the know about the little details, logic, etc, that should be worked on to support other functionality.

As you may guess, the product backlog tends to stretch and can turn into this massive endless monster of the list. To help deal with that, the Scrum team requires a superhero in the face of the product owner. The product owner plays a leading role in scrolling through the backlog, creating some kind of structure to it and translate it into simple schedule builder, and, most importantly, they lead the prioritization game. You can also use time planner for teams after prioritization to help your team with task organizing.

It is very important to work out the priorities, considering dependencies, business needs, resource consumption, and many other factors. Such a process may be led by the product owner, but it is largely supported by the development team with the occasional involvement of the stakeholders. Together, they brainstorm and analyze the future workload and come up with a better picture of what should be worked on, when, and for how long.

Backlog grooming

It is important to note that as the project goes on, priorities and plans can change, so the team will be re-visiting the sprint backlog lists at least once before every sprint starts. Plus, they can do it on demand during their Scrum meetings whenever the need arises. Scrum is a flexible framework, so there are no super strict rules, and the framework can be bent and transformed, especially if it benefits the team.

There is a separate backlog grooming meeting (also known as product backlog refinement) in the Scrum project management plan, which is scheduled by the team whenever they need it.

During the grooming session, teams:

• Go through the sprint backlogs
• Review every task individually
• Make sure every item results in value for the end-user
• Check for duplicating tasks
• Make adjustments if circumstances have changed.

The results of the product backlog grooming will be later used in the sprint planning meetings, where teams will come together again to work out what user stories (i.e. tasks) will be included in team planning software and worked on in the next sprint.

#2 Sprint backlog

Sprint backlog focuses on the present status of the team: what is the Scrum team working on right now during the upcoming sprint?

The sprint backlog is a part of the product backlog that was filtered, prioritized, and hand-picked for the current Scrum sprint. It is, essentially, a list of items that are the most crucial to execute at the moment.

The way the sprint backlog is selected allows the Scrum team to end the sprint with a shippable product increment. Meaning, even though the team will not finalize the solution, they will present some kind of working functionality that can be tested and used by the business.

The whole idea of Agile, and Scrum, in particular, is to deliver value in small chunks but more often. The value, in this sense, is a functioning product. The methodology is very popular because such an approach allows companies to get ROI faster and integrate the solution into the business processes sooner.

It is important to note that unlike the product backlog, where contributions from all project participants are welcome, the sprint backlog is designed strictly by the development team and the product owner.

The traditional project management method, such as Waterfall, would usually mean that all features and functionality are presented at the very end of the project. Sometimes, it could be up to a year, if not longer, before the stakeholders could see any sort of workable solution. Of course, such delayed presentations and reviews often lead to dissatisfaction with the solution, missing functionality, changing requirements, and lots of re-working to do.

Choosing what goes into the sprint backlog is a collaborative activity. It is essential that the product owner and development team work together, ask questions, and really listen to each other during the meeting. A lot depends on how well they will partner at this point.

It is a good idea to involve a Scrum Master at least in the first few rounds of planning the sprint backlog. Because there are more things to do than fit in the sprint, and sacrifices will have to be made, the Scrum team members might get into the wrong spirit of arguing, which should be mitigated by the Scrum Master.

#3 Product increment

Product increment focuses on a bit more strategic question: what will the end result of the sprint be?

The increment is presented by the development team during the sprint review and can be again evaluated during the sprint retrospective meeting.

The product increment is essentially the output that the team will produce by the end of the current sprint. It is everything that the team committed to complete at the beginning of the sprint.

One of the key criteria of the sprint success is whether the product increment is usable and can be shipped to the end-user.

Many consider the product increment to be the most important Scrum artifact. There is one product increment per sprint, and it is verified against the acceptance criteria, designed and approved at the beginning of the project and repeated during the sprint planning.

The list of acceptance criteria creates the definition of done. The definition of done helps everyone on the Scrum team share a common understanding of what it means for the product increment to be fully completed and ready.

Alternative Scrum artifacts

We have already mentioned that some teams expand the classical list to include other Scrum artifacts.

The most common tools that are excluded from the official Scrum artifact lists are:

• Burnup charts
• Burndown charts
• Sprint plans

Whether to consider them as artifacts or not is up to you. But we will cover them briefly to help you make up your mind.

Let’s start with the charts, which both represent the remainder of the work for the sprint versus the time left before the sprint finishes.

They are used during the sprint to help the development teams know where they stand in terms of progress. Additionally, these charts can be used for evaluation during sprint retrospective and sprint review meetings.

The burndown chart

The sprint burndown chart is usually created by the Scrum Master. It is a visual representation of work being completed through different sprints.

The vertical axis shows the work points. The horizontal axis shows time (sprints).

The burnup chart

This chart is also usually created by Scrum Masters, and it serves as an alternative to a burndown chart. It shows the same data but in a different way.

The advantage of the burnup chart is that it helps discover and visualize the things that we would never see with a burndown chart.

For example, if some of the work was assigned in the beginning and then removed at some point, a burnup chart will highlight it. If we use a burndown chart, then we will only see an abnormal spike in work done. That would lead to us thinking that the Scrum team is doing great when, in fact, they are just working as usual.

Similarly, if work was added at some point, we would be able to spot it with the burnup chart and not think that the Scrum team is behind schedule due to their own fault.

The sprint plan

The sprint plan is a document prepared during the sprint planning meeting. It comes in various formats and lengths, but it always defines the workload for the sprint:

• The main sprint goal.
• What needs to be done.
• How it will be executed.

Just like the charts, the plan can be utilized by the development team as a reference point during the sprint review or sprint retrospective meetings.

The Scrum planning phase is as flexible as the Scrum methodology, so every team decides individually what their sprint planning meeting and outcome should look like.

Final thoughts on Scrum Artifacts

Agile Scrum artifacts are great tools and facilitators of Scrum project management. They allow you to take back control over the sprint and work more efficiently.

The artifacts organize the entire projects’ work in 3 simple categories in your task tracker online:

• Absolutely all possibilities that we have for the project (the future).
• What we should be focusing on right now during the next sprint (the present).
• What is our progress on the way to the sprint goal (the value)?

The artifacts also promote the main Scrum values and philosophy of Scrum and Agile software development:

• The focus is on work that generates value. Unnecessary activities should be cut out from the team’s weekly planner.
• Transparency and openness, for example, achieved by using a shared calendar planner, are keys to success. Everyone understands what is going on at any point in the project.
• Teams are committed, respectful, self-organized, and motivated. Bureaucracy and micromanagement are non-existent because the team manages itself efficiently.
• Continuous improvement is prioritized by the whole team and enables to build a powerful, potentially releasable product by the end of each sprint.

Check out the Bordio blog, where we publish up-to-date, valuable content to help you learn new ideas and theories Agile, Scrum, general project management and more. And don’t forget to try out Bordio’s digital daily planner.