Entrepreneur - - By M. David Green

Scrum Artifacts: Stories

scrumthumb

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

ch5-01

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.

Sponsors