What are Scrum Artifacts?
| technology | programming - Ross Heintzkill

What are Scrum Artifacts?

Scrum is an approach to project management that can be pretty uninviting to newcomers and confusing to people who aren't familiar with it. People on the outside, people who haven't learned Scrum, might feel like Scrum is more of a club or a secret society than a way to organize organizations and projects. One of the things that can make it tough to get into is the vocabulary.

Even its name, Scrum, doesn't exactly bring project management to mind. And then there are "backlogs", "sprints" and "artifacts". In this blog post, we'll cover the last one, we're going to explain what people mean when they talk about "artifacts" in Scrum. We explain what a Scrum artifact is, and what the most common artifacts are. This won't make you an expert in them, but it should shed some light on what people are talking about when they talk about Scrum ideas like backlogs and stories.

What is Scrum?

Quick definition: Scrum is a project management methodology. In other words, it's a framework for planning projects, keeping track of progress, and actually developing and delivering products. Scrum is a specific set of rules and approaches to project management within the broader Agile project management approach.

What is a Scrum Artifact?

Quick Definition: In the Scrum project management methodology, the word artifact is a versatile term: it describes the place where information about a project is kept, but it can also refer to some of the information itself. Broadly speaking, a Scrum artifact is an actual, (usually) physical object that contains details about projects and products being worked on. Updates and progress on products get added to and removed from different artifacts at certain times so that everyone working on a project can quickly understand a project's status.

An Overview of Scrum Artifacts [VIDEO]

In this video, Steve Casely covers various aspects of Scrum Artifacts that are associated with Scrum Development. Scrum Artifacts include the User Story, Product Backlog, Sprint Backlog, and Progress Charts. He'll walk through each of these, defining and then explaining how you can use it.

What Are the Key Scrum Artifacts?

The key Scrum artifacts are the User Story, Product Backlog, Sprint Backlog and Progress Charts, and we'll go over each of those in some detail. Artifacts in Scrum are specific things – it's not a broad word that can be applied to any piece of information about a project. The versatility and strength of Scrum is that although there are a limited number of artifacts associated with the Scrum development process, each of them is crucial to the overall success of good, productive scrum delivery.

As a project management approach, Scrum is most often applied to software development, but it can apply to most products and projects that undergo repeated iterations on the way to delivery. Understanding the Scrum artifacts that store and communicate the status of individual projects and products is key to making Scrum work right for you and your project management process.

The key artifact is the User Story. The job of a user story is to identify the actual business functionality that needs to be delivered by the project. A user story is written in a particular format and answers questions in a recognizable way.

Another important Scrum artifact is the Product Backlog. The product backlog is actually a compilation of user stories. Stories that are awaiting completion are listed on the product backlog, and it contains no other information other than the stories.

The Sprint Backlog has similarities to the product backlog. As a project moves forward through the Scrum process, stories get removed from the product backlog and moved into a specific sprint backlog. A sprint is a defined, 2-4 week development cycle, and a sprint backlog identifies the stories that need to be completed in the next sprint.

Finally, Progress Charts are the last Scrum artifacts we'll talk about. As you might gather from their name, progress charts are where either the remaining work or the work that's been completed gets tracked. Progress charts are the Scrum artifact that are best for tracking overall development.

What is a Scrum User Story?

A Scrum user story defines a unit of work that needs to be accomplished. It does that in three parts: first, it captures something that a user needs added to or modified in the product. If you're more familiar with IT terminology, it's a requirement. Second, it explains how to test that the requirement is completed. Third, it explains the urgency and predicted difficulty of making the change. A Scrum user story is arguably the most important artifact in all of Scrum.

Maybe the most important aspect of a Scrum user story is that it's a very focused, specific piece of requirement. In fact, Scrum official recommendation is that each user story should be written on a blank, 3.5" x 5" index card. That way, you can't put too much detail or create too big of a requirement.

To keep user stories predictable, they have to be focused. And to focus them, there's a specific format that's recommended and preferred. Basically, that format says the story should be written from the perspective of someone actually using the product trying to accomplish a specific thing, for a desired result.

A story is written out with a template in three parts: (1) "As a type of user", (2) "I need to do something", (3) "So that a result happens". An example user story might be "As a warehouse clerk, I need to find a product in the warehouse, so I can ship the product to a customer."

But like we said earlier, that's only the first of three parts. The second part is the definition of what "done" means for that story. Sometimes, the end result for a story's success is obvious, but sometimes exactly what the user is looking for or needs is particular or nuanced.

The second part of a Scrum user story is called the Acceptance Criteria, or how to tell when the desired result has been achieved. It's important to include, because not every story's success state will be the same as every other. A good acceptance criterion is something tangible that the user and the developer can point at afterward and say, "This story has been accomplished." In the case of our earlier example, the acceptance criteria might be "I (the warehouse clerk) have a picking slip that tells me where the product is."

Can you see how the user story would be different if the person writing it hadn't specified that they need a picking slip? But it's also important that they didn't say a picking slip was their requirement. They don't need a picking slip — they need to know where the product is. The developer who goes to handle this user story now understands what the underlying need is, but also what the expected result for the user is.

With that understanding passing between the developer and user, one thing remains: the urgency and difficulty. And that's the third part of a Scrum user story: Business Value and/or Prioritization. This part of the user story is used by the development team to pick what stories get done in what order – and to explain that, we'll move on to one of Scrum's other artifacts: the product backlog.

What is a Product Backlog in Scrum?

The Scrum Product Backlog is a visual presentation of stories. It holds and shows all the upcoming work that's been identified for the product. In Scrum, the product backlog is the artifact someone can consult to get a sense of each piece of work that remains to be done for a product's development. As user stories get written, they get added to the Product Backlog, so all members have a visual representation of what the current needs are for that project.

A product backlog is usually a physical object or space. Often, an entire wall in the workspace is used, or at least a corkboard. The great thing about the product backlog is that stories actually get physically placed and moved around on it. As they get dreamt up, people put them on the board, and as they're completed, they move off of it.

The layout of the product backlog is important, but it can change for every team. Typically, new stories get placed into a field of the board labeled "Business Stories". Many stories will live in that section for a while before getting moved to the section of the backlog labeled "Sprint-Ready Stories". The key difference between a first-identified business story and a sprint-ready business story is that by the time it goes to Sprint-Ready, every aspect of the story — all three pieces — are filled in.

Often, the stories placed under Business Stories only have some of their data. So maybe we know that "as a warehouse clerk", but we don't know the definition of "done" yet, and we don't have the prioritization yet.

There can be many categorizations on your product backlog, but one of the typical delineations is between Business Stories and Sprint-Ready Stories.

Another category on your product backlog might be Epics. Epics are simply very large business stories that need to be further decomposed. You might put an epic in the Epics section while you wait to break it down into multiple business stories.

You could also have an entire section on your product backlog labeled Documentation — and there you might put stories specifically associated with requirements for documentation. For example, maybe you need a training manual written for the product you're developing, or a chapter added to the existing manual for a feature that's getting added.

There are all sorts of potential sections of your product backlog and labels that might categorize the stories that get placed there. Maybe you have stories associated with specific training. Or stories related to a specific team, or stories associated with technical debt.

The point of the product backlog is to be useful, and to give a sense to whoever looks at it about what requirements have been identified for the product overall. How you categorize your stories is going to be based on the type and nature of the project that you're working on.

What is a Sprint Backlog in Scrum?

The next logical artifact to discuss is the Sprint Backlog. In Scrum, the sprint backlog identifies and displays the work that's being actively worked on and will be finished within the next few weeks.

A sprint is a Scrum concept, it's an amount of time, usually 2-4 weeks long. Sprints are the iterations in which the work on a product gets done. In Scrum, the sprint backlog is the work that's decided on at the start of the sprint. All the stories that will be accomplished throughout a sprint are agreed on before the sprint starts, and once a sprint starts, it's very uncommon to add new stories or remove existing ones.

The sprint backlog has three columns: To-Do, In-Progress, and Done. During the sprint planning process, stories are removed from the product backlog and put on the sprint backlog according to their priority. The highest priority stories get moved over to the To-Do column of the Sprint Backlog.

Stories in the to-do column identify what has yet to be done in the time remaining in the current sprint. And just like stories move through the product backlog, the stories move around on the sprint backlog. Scrum user stories start in To-Do. When someone begins work on a story, they manually move the card to In-Progress. Only when they're finished and the acceptance criteria has been verified do they get to Done.

By the end of the sprint, all stories should be in the done column. If not, the sprint wasn't well-planned, or the expected difficulty of various stories was incorrectly predicted.

What are Scrum Progress Charts?

The last Scrum artifacts to discuss are progress charts. In Scrum, progress charts monitor the progress of development as stories move from the product backlog to the sprint backlog and as stories move through the sprint backlog. The two charts typically produced are either a burndown chart or a burnup chart.

The two charts are simple enough, and the difference between them is pretty obvious. A burndown chart tracks the total number of all stories in the backlog and tracks how that number decreases over time as more sprints address the stories. On the other hand, a burnup chart identifies the number of stories that have been completed. In Scrum, a burndown chart is basically a view of "to-do", and burnup charts are a "done" view.

At a sprint level, we have the same styles of charts — we can identify the work or stories. But typically, at a sprint level, we can be a little more granular and we identify the specific work packages — the individual amount of work assignments. And we track the progress, recognizing that there may be small hiccups in our work progress where some of our estimates were simply wrong and we identified more work that needed to be done. And here too we can do it on a burndown or a burnup to track the progress through the sprints.

Final Thoughts

Scrum is a fascinating program management framework, for developers, engineers, administrators and project managers equally. The heart of Scrum is breaking down complex products into specific, deliverable expectations and then allowing distraction-free time to get them done.

Download

Download

Ultimate Project Management Cert Guide

A 49-page guide to every PMI, Scrum, and ITIL certification, and how they fit into your career.

By submitting this form you agree that you have read, understood, and are able to consent to our privacy policy.

LEARNING ON MOBILE

Learn anytime anywhere with our mobile apps.

I have read and understood the privacy policy and am able to consent to it.

© 2021 CBT Nuggets. All rights reserved. Terms | Privacy Policy | Accessibility | Sitemap | 1550 Valley River Drive, Eugene, OR 97401 | 541-284-5522
CBT Nuggets
www.000webhost.com