Scrum Artifacts

Scrum contains three main artifacts: product backlog, sprint backlog, and the burn-down chart. These artifacts are the by-products of the Scrum activities and help give direction and transparency to the team. In addition to these main artifacts, there is also an important secondary artifact: acceptance criteria.

Product Backlog
The product backlog is a list of all work remaining on a project that the team needs to complete. This list represents the customer�s product needs and wants. At the heart of this list is the user story, a key component of Scrum. It defines the increment of value to the customer that the developer is trying to deliver.

The product backlog is managed by the product owner, who is responsible for adding and removing user stories to and from the list. The product backlog is constantly prioritized by both the product owner and the customer. This constant prioritization is the key to Scrum. It ensures that the user stories that provide the greatest value to the customer are listed at the top of the product backlog. As user stories are added, they are compared to the user stories already on the list to see where they fit in value to the customer. During a sprint, user stories can be added to the product backlog, however, they will not be presented to the team until after the current sprint is completed.


User Stories
As mentioned earlier, the product backlog is nothing more that a prioritized list of user stories. A user story is a card that describes an increment of value to the customer. The user story is written for the developer in order to express the increment of value. The key to a good user story is that it is a vertical slice through the product. A horizontal slice is a feature that just touches one level, such as the database level or the UI (user interface) level. A vertical slice, on the other hand touches all the levels of the product. This is the smallest amount of work that touches all levels of the product and still provides value to the customer. By writing the user stories in a way that allows for vertical slicing, you can create basic functionality in the first user story and then easily add functionality to this feature as the customer needs it.

A way to make sure that a user story accomplishes the goal of being a vertical slice through the system is to make sure that it fits the INVEST acronym. INVEST2 stands for:
� Independent: The user story should be self contained, so that there is no inherent dependency on another story.
� Negotiable: User stories, up until they are a part of a sprint, can always be changed and rewritten.
� Valuable: A user story must deliver value to the end user.
� Estimable: You must always be able to estimate the size of a user story.
� Sized appropriately: User stories should not be so big as to become impossible to plan/task/prioritize with a degree of certainty.
� Testable: The user story or its related description must provide the necessary information to make test development possible.


Backlog Sizing
Sizing the product backlog is a measure of the pace at which the Scrum team can deliver items. People are not good at estimating work. We all know how terrible we are at accurately estimating how long something will take us to complete. How many times have we heard or said ourselves, �I am 80 percent complete on this. The remaining 20 percent will be done in an hour.� Yet two days later, it�s still not done. People are just naturally bad at estimating.

We may not be good on our estimates, but we are great at comparing things. For example, we are able to look at two cooking recipes and tell which one is more complex without being a professional chef. We can look at two items and see that one is larger than the other. Sizing the backlog is all about making decisions based on the complexity and amount of work, not on how long it will take to do the work. Sizing is not equal to estimating.

You may ask: how do I know how long something will take? Consider, as an example, a manager who wants to know how long it will take your team to produce a widget. You can derive the time estimate of completing the widget from the complexity of the widget. After your team has gone through a sprint, you can then look at that sprint and calculate how long it took the team to complete it. The team is only concerned with how complex a task is.

To perhaps better explain the idea of estimating the amount of work over the time to complete it, let�s compare it to painting your house. Let�s say you went to your local hardware store and bought several gallons of paint to paint your house. Then you call three contractors to give you an estimate on painting the house. The first contractor comes out and walks around the house, looks at all the buckets of paint you bought, and explains that he has old rusty ladders and handheld brushes and a scrawny kid to help him, so it will take him two days to do the job.

The second contractor comes out and walks around the house, looks at the buckets of paint, and explains that he just recently purchased new ladders and brushes, and the local high school varsity football team is working for him that weekend. With all those hands and the new equipment it will only take him a day to paint your house.

The third contractor comes out, walks around the house, looks at the paint, and explains that he owns some brand new mechanical paint sprayers and top-of-the-line machinery and he can have the house painted by lunch time.

What you see in this story are three contractors with three different time estimates on how long it will take to paint the house, but there is one thing that did not change throughout all of this and that is the size of the house and the amount of paint. No matter who was doing the job, the house size never changed, even though the time estimates did. The moral of the story is to do your best not to estimate the duration of the work, but instead estimate the amount of effort it will take to complete the work. Once you have the estimation of the amount of work, you can derive the duration to complete the work.


Sprint Backlog
The sprint backlog is a list of all work remaining in a sprint that needs to be done by the team. Think of the sprint backlog as a subset of the product backlog. Whereas the product backlog lists all the user stories remaining for the product, the sprint backlog contains all the user stories and tasks remaining for the sprint. Typically when a user story is chosen for a sprint, the team will split that user story into tasks. A task is a small chunk of the user story that can be done by any member on the team. Examples would be a task to implement the database changes needed for the user story, or a task to implement the UI for the user story. These tasks are displayed on a task board�also known as a Kanban3 board�that is visible to the entire organization. Other items can appear on this board as well, including information on set-up meetings to gather requirements, review checks, research, testing, design, and stages of coding.
Team members take a card from the board and during the sprint commit to doing the task the card describes. As team members work through tasks, other tasks may emerge and original estimates are adjusted. All members of the team are responsible for updating the Kanban board based on new information gained on the feature being worked on.

The sprint backlog supplies the information needed by the burn-down chart. At the end of each sprint, the sprint backlog is emptied. Any remaining items on the backlog are pushed back to the product backlog, where they are reprioritized against user stories currently in the product backlog, in addition to any new user stories that were added during the sprint.


Burn-down chart
A burn-down chart is a visual way to track how the sprint is progressing. The chart graphically shows the amount of remaining work on any given day of the sprint. It is usually displayed in a public area where anyone can see it. This aids the communication among team members and anyone else in the organization. This chart can also act as an early indicator that there is a problem in the sprint and the team may not be able to fulfill the commitment.


Acceptance Criteria
Although product backlog, sprint backlog, and the burn-down chart are the primary parts of Scrum, acceptance criteria is a very important secondary artifact in the Scrum process. Without good acceptance criteria a project is doomed to fail.

Acceptance criteria is essentially a clarification of the story. It gives the developer a set of steps that must be completed before the story can be considered done. The acceptance criteria are created by the product owner with the help of the customer. It sets the expectation of the user story. With this in place, a developer has a great starting point in which to write automated tests or even use test-driven development (TDD). In this way, the developer is creating something that the customer needs and wants with the understanding of how the customer will use it.

Another benefit of acceptance criteria appears when a feature cannot be completed in a sprint and needs to be spread out across sprints. Then the team can use the acceptance criteria as a tool to see where the user story could be broken into smaller pieces that still provide value to the customer, but can be completed in a sprint.
Source of Information : Pro Agile .NET Development with SCRUM