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 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.

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.

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

Acceptance Criteria:

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

Acceptance Criteria:

and

and

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.

Stories for the development team emerge from the product owner's product backlog. A product backlog keeps track of all the input the product owner has about the direction of the product from the client, along with the research, experience testing, design, and engineering feedback the product owner has gathered.

Unlike stories for the sprint backlog, items for the product backlog don't need to be structured in any particular way. That's because their main purpose is to allow the product owner to keep track of all of the features that are needed. These product backlog items may be quite vague until they crystallize into a clear development story for the sprint backlog. Items in the product backlog should always reflect the product owner's latest thinking about the long-term goals for the product, while the team is working on the specific features for the current increment.

While many product owners prefer to keep track of items in the product backlog as if they were going to become the final stories, there doesn't have to be a one-to-one correspondence between items in the product backlog and stories that make it into the sprint backlog. Features and requirements that the product owner needs to track may turn into multiple stories, or several items may be combined to create one unified story of the appropriate size and scope for development.

For example, if the customer needs to add a payment system to a site, that may be a single story for the development team, or it may be multiple stories. There may be developer stories around creating the ability to accept payments through a service, and separate stories for accepting credit cards, checks, or even maintaining a token system so that purchases can be made using a virtual currency. It might be possible to develop each one of these independently, and launch the system with just one. Whichever one goes out first may need to carry the weight of implementing some core functionality that all the others will share.

Many product owners find it convenient to track the state of items in the product backlog using a staged process, whereby the item moves from ideation through design through engineering validation, until it's ready to be phrased as a sprint backlog story and added to an upcoming sprint. Product owners should have a clear sense of what it takes to move an item from each of the states to the next, and that should be documented so it'll be consistent for each story.

The sprint backlog is the set of developer stories that the team has committed to working on during the current sprint. A sprint backlog is created as part of the sprint planning ritual, and reflects the shared understanding of the team, the product owner, and the scrum master of what everybody will be working on for the coming sprint.

A sprint backlog consists of a set of feature stories. Each one of these stories emerged from the thinking process that came out of the product backlog, but may not reflect a specific item in the product backlog. The feature stories in the sprint backlog follow the story structure we described earlier.

The size of the sprint backlog for the current sprint is based on the negotiations that happened during sprint planning at the beginning of the sprint. Each story is estimated during the sprint planning, and the backlog as a whole should represent the total number of points that the team believes it can accomplish in the upcoming sprint. Each story has a point value, and that reflects the amount of work the team believes will be necessary to complete that particular story.

The order of the stories in the sprint backlog is established initially at the sprint planning ritual, but it's the prerogative of the product owner to change the order of stories in the sprint backlog at any point during the sprint. The product owner may not add stories to the sprint backlog, or remove stories from the sprint backlog, but may rearrange them as necessary to indicate which stories are most important.

During the sprint, developers pick stories from the top of the sprint backlog every time that they complete a story and need something new to do. Each engineer should choose the story at the top of the backlog, because that's the one the product owner considers the highest priority in the current sprint. Picking stories that aren't from the top of the backlog will result in work being done out of priority order.

The sprint backlog is often the first column of the scrum board. A scrum board tracks the progress of all the stories being worked on in the current sprint until it meets the team's definition of done. Most scrum boards use two or three columns, and move stories from one column to the next to reflect which stories are in the prioritized backlog, which are in progress, which are in QA, and which are ready to be demoed.

Scrum boards provide a focus for the entire team. By looking at the stories on a scrum board during the sprint, anybody on the team should be able to get an immediate snapshot of where the sprint stands, and how the team is progressing toward meeting the goals it set for itself. A good scrum board should be public, so that people outside the team can also take a look and see what's happening, encouraging transparency across the company.

There's wide range of tools available for monitoring the progress of stories through a scrum board. The most basic approach is simply keeping index cards taped to a wall where everybody can see them. For teams that are co-located, this serves a number of useful purposes. Not only does it encourage the use of index cards and handwriting for keeping stories short and succinct, it also creates a natural gathering place for daily standups, as well as a shared visual reminder of where the team is up to.

Apart from using a physical board, many companies have developed electronic tools and services that are designed to help teams capture and manage stories as they move from one state to the next. Some of these tools include the ability to track points, generate standard reports, and even set access and privacy levels. There are tools that allow teams to trigger automated build processes in a continuous integration by updating stories. Some tools tie into bug tracking systems commonly used across a wide range of industries, facilitating communication with clients and users. Others tools may simply support the electronic tracking of a story as a card, while allowing everybody to see everything and make any changes.

Among the most popular current online scrum board management tools that allow shared story management and tracking of points, velocity, and various states for each story in progress are:

Some teams prefer electronic tracking tools so they can be accessed online remotely, or displayed on a large monitor where the team can see it. The field of possible tools is constantly evolving, and any specific recommendations would quickly grow stale as new players enter this fast-moving field. In addition, companies creating these tools have different philosophies about how scrum should work. Those philosophies are reflected in the way the tools are designed.

Changing tools can be a difficult process, and few tools will support direct export in a format that a competing tool can import directly. It's up to each team to decide which tool's philosophy best matches their own approach, and find one they can stick with. A good scrum master should be familiar with the tradeoffs associated with different options.

We've mentioned the definition of done a few times. The definition of done applies to each story in a sprint backlog. Declaring a story to be done is a means of verifying that all of its critical aspects have been completed based on the way each team works.

It's vital for a team to have a shared idea of what done actually means for itself. Teams should create a written definition of done which they maintain as a checklist for every story they work on. This definition should be independent of the documentation for a specific story or project, because the definition of done should apply to the way a team works, independent of what they're working on.

A definition of done is something the team should come up with together. It may be created during the first sprint planning, and iterated on during sprint retrospectives. A team's definition of done may involve radically over time, as the team realizes during retrospectives what aspects of the process may need improvement.

It's not a bad idea to publish the definition of done prominently. This allows people both on the team and outside the team to understand just how much effort is involved in completing any story. This document provides a reference point for questions about whether or not a proposed story is ready to be worked on. If it's impossible for story to meet the definition of done based on the acceptance criteria, having a published definition of done can help the team make that clear.

Usually a definition of done includes a number of familiar expectations. For example, the code should be complete, the build shouldn't fail, the test suite shouldn't be broken, and the product should run as expected. Other points often included in a definition of done include peer reviewing code, writing new unit tests, code commenting, and updating product documentation. Different teams will have different requirements, and the exercise of creating a definition of done is valuable for helping the team realize what's important for every story, not just certain stories.

Velocity is how a scrum team measures the amount of work they can complete in a typical sprint. Velocity is measured historically, from one sprint to the next. By tracking the number of story points the team can complete according to their own definition of done, they can build up a reliable and predictable sense of how long it will take them to complete new stories based on their relative point value.

Keeping track of the velocity is the responsibility of the scrum master. At the end of each sprint demo, the scrum master should calculate the number of points that were estimated for the stories that were accepted as done during that sprint. This number should be added as a data point on the velocity chart for that sprint.

Velocity charts tend to start out jumping around from very high numbers to very low numbers, as the team learns how much work they can do in a sprint, and how to estimate stories. The longer a team works together, the better they get at estimating stories consistently relative to each other. That skill leads to a better sense of how many stories, and how many points, the team can accomplish in a single sprint.

Over time, if the composition of the team stays consistent, a velocity chart that started off very erratic will start to find itself averaging toward a consistent value. Unlike many charts in a business environment, the point of the velocity chart isn't to see a constant increase, but rather to see the values converging around a consistent horizontal line. That line represents the amount of work the team can realistically and sustainably accomplish in a single sprint.

A burndown chart shows the team's progress toward completing all of the points they agreed to complete within a single sprint. This chart starts with the total number of points the team has taken on for the sprint, and tracks on a day-to-day basis how many of those points have been completed and are ready for the sprint demo.

The burndown chart is usually maintained by the scrum master, and may be updated on a daily basis, perhaps after the daily stand up, or on a continuous basis if it's generated automatically by the tools the team is using to maintain the scrum board. The primary audience for a burndown chart is the team itself, although there may be data points on a burndown chart that could be relevant to people outside the scrum team.

A typical burndown chart starts with a straight diagonal line from the top left to the bottom right, showing an "ideal" burndown rate for the sprint. In practice, the point is not to match that ideal, but rather to keep in mind how much of the sprint is left at any point in time, and how much effort the team expects to be able to put toward the development of the product on any particular day of the sprint.

Lines or columns on the burndown chart may be used to represent the number of points of effort actually remaining in the sprint from day-to-day, starting with the number of points the team has committed to at the sprint planning. As work is completed, these columns should become shorter until they reach zero.

Some teams also choose to track the daily work completed, either in story points or in individual tasks toward completing stories. This can be done with a line or stacked columns, tracking these daily metrics against the burndown chart so they can be viewed in context.

There are very few legitimate reasons for a column to be taller on one day than it was on the previous day. If a bug is discovered before the end of the sprint, and a story that was marked as done or ready to demo needs to be worked on again, columns may increase in size from one day to the next. New stories introduced after the sprint has started may also cause one day's column to be higher than the previous day's. A pattern of rising columns on a burndown chart may indicate that the scope of the work is exceeding the originally agreed sprint backlog, which is definitely an anti-pattern in scrum.

The final artifact of scrum is the actual product increment as it exists at the end of a sprint, with all of the stories in that sprint which met the definition of done incorporated. At the end of each sprint, the completed features that were worked on should be added to the product for the sprint demo. At that point, the product itself is an artifact of the scrum process.

A goal of the scrum process is to develop features in such a way that the product is in a completed state at the end of every sprint, so it could be released, demonstrated to clients for feedback, or used as a tool for testing. While it's not mandatory for an organization to release the product according to the schedule of scrum, this goal allows the state of the product to be part of the iterative process of development, testing, evaluation, and innovation that scrum encourages.

Ownership of the product increments should belong to the release engineers in most organizations, and should be fully available to the product owner. For web and mobile projects, often the product increment is a live demo branch of the product, maintained in a secure but accessible location.

For teams doing continuous integration, the live site may always reflect the latest work done by the team. In these cases, the public site or app will be the product increment.

These are a lot of new terms to become familiar with, but getting comfortable with the names and features of the scrum artifacts is a good place to start when learning about scrum. In this chapter, we've gone over stories, product backlogs, sprint backlogs, scrum boards, definitions of done, velocity charts, burndown charts, and product increments. And with that, we've covered the mechanics of scrum for web and mobile development!

Now that we have a handle on the roles, rituals, and artifacts of scrum, it's time for us to take a look at the scrum contract. What is someone agreeing to when they start to work as part of a scrum team? What does it mean to work transparently? How does iterative improvement change the way we approach problem solving? We'll be discussing all these issues and more in the next section.