The following is an extract from our book, Scrum: Novice to Ninja, written by M. David Green. Copies are sold in stores worldwide, or you can buy it in ebook form here.
Artifacts are the tools of scrum that allow teams to manage their scrum process. They help team members communicate about the work they’re doing, and provide a record of what the team has agreed to do and what they have accomplished. Anyone can point to the artifacts of a scrum team to show people what they’re working on, what they’ve accomplished, and what they expect to be able to achieve.
There are a number of artifacts that help teams prepare and manage as part of the process of working in scrum. Getting familiar with the language of scrum means understanding what each of the artifacts is for, and how it’s used. In this chapter, we’ll go over a few of the most common scrum artifacts, such as:
-
story
-
product backlog
-
sprint backlog
-
scrum board
-
definition of “done”
-
velocity charts
-
burndown chart
-
product increment
Different teams have different approaches to how they create and maintain the artifacts they use, but for web and mobile development, some are worth keeping in mind.
Artifacts Overview
Although formal scrum is agnostic about exactly how the artifacts of the process are used, we’ll cover a few ways of building and maintaining artifacts found to be useful for the type of work that web and mobile teams tend to get into.
One of the most basic artifacts of scrum for web and mobile work is the story that describes a feature to be worked on. Stories are developed and managed in backlogs. Separate backlogs are maintained for the product owner to keep track of the overall vision of the product, and for the team to participate in the sprint currently in progress. Both backlogs house descriptions of what needs to happen to take the product forward, but items on the product backlog will not look like stories on the sprint backlog. Scrum teams use a scrum board for tracking the progress of stories through the sprint, and we’ll discuss how those work together.
Scum also offers a number of tools for gathering statistics that are useful for tracking the performance of the team, and communicating how product development is going to people both inside and outside the scrum team. Among these, we’re going to cover the velocity chart that spans multiple sprints, and the burndown chart that tracks progress within a single sprint.
Other artifacts that a scum team is going to find useful include a definition of done, which is agreed to by the product owner and team under the supervision of the scrum master, as well as the actual product increment, or the current state of the product as it exists at the end of the sprint.
Stories
Stories are how the product owner communicates to the development team what needs to be developed. Stories are incubated in the product backlog, and then expressed in a standard format so they can be presented to the team as part of the sprint planning meeting to be evaluated, estimated, and then included in a sprint backlog.
Note: The Origin of Using Stories
The concept of using a story to encapsulate discrete parts of the work comes from Extreme Programming (XP), which is a specialized variation of agile that advocates a number of excellent development practices such as pair programming and writing feature stories. Stories come in very handy when doing web and mobile development with scrum, where the work on a full slice of functionality generally includes many of the same components from the back end to the front end. The team will often see stories that all have the same components, and comparing one story to others the team has worked on before makes new stories easier to break down and estimate relatively. For that reason, we’re going to consider stories a basic artifact of scrum for the type of work we’re talking about.
A story should capture a complete slice of functionality. Each story should be independent, so that developers don’t have to complete one story before working on another. A story should be a small slice of functionality that can be worked on and completed over the course of a single sprint.
Stories help capture the essence of a feature, and give the team the ability to discuss the parameters and acceptance criteria in a meaningful and relative manner. Estimating work by sizing feature stories around what the team can accomplish in a sprint is a useful exercise.
Every story should add to the value of the product, and bring it closer to the vision of the product owner. Each story should make it clear how the product owner will test the final product to verify that the story has been completed.
Note: Stories Aren’t Technical Specifications
Although new product owners with backgrounds in engineering or product management sometimes feel inclined to work out all the technical issues and propose static solutions with fully fleshed out specifications for every feature, it’s important to keep in mind that scrum stories aren’t technical specifications. They are opportunities to open a discussion between product owners and engineers about how to implement a feature, and how much effort will be involved. That’s one of the reasons stories follow a short and consistent format. It undercuts the temptation to include more detailed specifications.
The responsibility for writing the stories belongs to the product owner. Writing stories that capture the full intention and expectations of the client is a skill that may take time to develop, but it’s critical to an effective scrum process. A good scrum master should be able to help coach the product owner in how to write stories that are the right size, express the appropriate acceptance criteria, and open a dialogue rather than close one off.
There’s a simple formula that works well for writing stories. People have tried many variations over the years. Through iteration and reflection, different teams may eventually evolve different approaches that work for them, but this is a good place to start:
Name: brief understandable feature name
-
As a type of user
-
I want to behavior
-
so that justification for the behavior
Acceptance Criteria:
-
Given a defined state
-
when a set of conditions or events
-
then a consistent and testable result
Note: What makes for a good story?
A good story is short and straightforward. Many scrum teams follow the convention that a story should be able to be written on one side of an index card, three inches by five inches, with the acceptance criteria written on the back of the same card. If it takes more than that much information to write down the story, the specifications may be too detailed, or story may be too complex, and may need to be broken down into multiple stories.
For example, consider a team developing a gallery application. Visitors to the gallery might want to rate the images being displayed, so they can keep track of their favorites. The gallery can function with or without the rating feature, so the work can be isolated as a complete slice of functionality. And according to the engineers, the work involved in adding a rating widget can be completed within a single sprint.
This is how a story might be written so that the team can evaluate it, estimate it, and commit to it in a sprint backlog:
Name: Rating Gallery Images
-
As a gallery viewer
-
I want to rate the images
-
so that I can track and rank the images I’ve rated
Acceptance Criteria:
-
Given a logged-in user viewing a gallery
-
when the user clicks a star in a rating widget for an image
-
then the value of that star should be recorded as that user’s rating for that image
and
-
Given a logged-in user viewing a gallery
-
when an image the user has rated is displayed
-
then the rating widget should reflect the user’s previously entered rating
and
-
Given a logged-in user viewing a gallery
-
when the “Favorites” switch is toggled on
-
then only images the user has rated should be shown, in descending order of rating
For a story such as this one, the team may have a standard for how wireframes or designs get attached to stories and communicated. For example, if this is a new widget, the designer may have prepared a mockup and a set of assets that the engineers will need in order to implement the feature. There may also be a style guide or other documentation for the product that needs to be updated with the relevant information.
The story is agnostic about engineering decisions, such as how the API is designed, or what naming conventions are used in the code. While the definition of done for the team may include the need to create documentation about technical aspects such as this, the story that the product owner presents usually doesn’t need to have an opinion on these points.
When a story is presented at sprint planning, the engineers should verify that all of the necessary assets and information they’ll need have been captured and are available. The actual work to be done in the upcoming sprint is defined by the description on the story card and the dialogue it inspires between the product owner and the team.
Frequently Asked Questions (FAQs) about Scrum Artifacts
What is the importance of Scrum Artifacts in Agile methodology?
Scrum Artifacts are essential components of the Agile methodology. They provide a framework for managing and tracking the progress of a project. They help in creating transparency and visibility for all team members and stakeholders. These artifacts include the Product Backlog, Sprint Backlog, and the Increment. Each of these artifacts serves a unique purpose and contributes to the overall success of the project. They help in setting clear expectations, defining goals, and ensuring that everyone is on the same page.
How does the Product Backlog contribute to the Scrum process?
The Product Backlog is a prioritized list of features, functions, requirements, enhancements, and fixes that need to be developed for a product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for managing the Product Backlog, including its content, availability, and ordering. It helps in planning and scheduling the work for future Sprints, thus playing a crucial role in the Scrum process.
What is the role of the Sprint Backlog in Scrum?
The Sprint Backlog is a list of tasks identified by the Scrum Team to be completed during the current Sprint. It is a highly flexible artifact that changes and evolves throughout the Sprint based on the team’s progress and discoveries. The Sprint Backlog helps in managing the work within a Sprint and provides a clear view of what the team is working on and what they plan to work on next.
How does the Increment contribute to the Scrum process?
The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. It provides a tangible output at the end of each Sprint, demonstrating the progress made towards the overall project goals. The Increment should be in a usable condition, regardless of whether the Product Owner decides to release it.
How are Scrum Artifacts used in Sprint Planning?
During Sprint Planning, the Scrum Team uses the Product Backlog to determine what can be delivered in the upcoming Sprint and how the work will be achieved. The team selects items from the Product Backlog to include in the Sprint Backlog. Throughout the Sprint, the team works on the tasks in the Sprint Backlog, resulting in a new Increment by the end of the Sprint.
How are Scrum Artifacts used in Sprint Review?
In the Sprint Review, the Scrum Team and stakeholders inspect the Increment and adapt the Product Backlog if needed. The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”. Based on this and changes to the Product Backlog during the Sprint, attendees collaborate on what to do in the next Sprint.
How are Scrum Artifacts used in Sprint Retrospective?
During the Sprint Retrospective, the team reflects on the past Sprint with the aim of continuous improvement. They discuss what went well, what didn’t, and how they can improve in the next Sprint. The Scrum Artifacts, particularly the Sprint Backlog and the Increment, provide valuable insights for these discussions.
How are Scrum Artifacts used in Daily Scrum?
The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. The Developers plan work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one. The Sprint Backlog plays a crucial role in this event.
How can Scrum Artifacts help in managing project risks?
Scrum Artifacts provide transparency and visibility into the project’s progress, which can help in identifying and managing risks early. For example, if the team is consistently unable to complete the tasks in the Sprint Backlog, it may indicate a risk that needs to be addressed.
How can Scrum Artifacts contribute to project success?
Scrum Artifacts provide a framework for planning, managing, and tracking the progress of a project. They help in setting clear expectations, defining goals, and ensuring that everyone is on the same page. By providing transparency and visibility, they enable the team to identify and address issues early, thus contributing to the overall success of the project.
M. David GreenI've worked as a Web Engineer, Writer, Communications Manager, and Marketing Director at companies such as Apple, Salon.com, StumbleUpon, and Moovweb. My research into the Social Science of Telecommunications at UC Berkeley, and while earning MBA in Organizational Behavior, showed me that the human instinct to network is vital enough to thrive in any medium that allows one person to connect to another.
