Scrum Artifacts
Scrum Artifacts – results/products of our management activities – are designed to increase transparency of information related to the delivery of the project, and provide opportunities for inspection and adaptation.
There are six artifacts in Scrum:
- Product Backlog: An ordered list of everything (aka stories) that might be needed in the final product
- Sprint Backlog: Selected items (stories) from the Product Backlog to be delivered through a Sprint, along with the Sprint Goal and plans for delivering the items and realizing the Sprint Goal
- Increment: The set of all the Product Backlog items completed so far in the project (up to the end of a certain Sprint)
- Definition of “Done”: The shared understanding of what it means for a piece of work to be considered complete
- Monitoring Progress towards a Goal: The performance measurement and forecast for the whole project
- Monitoring Sprint Progress: The performance measurement and forecasts for a single Sprint
Items 5 and 6 might look more like activities, but they are considered artifacts in the Scrum Guide, and therefore we will explain them as so. You can imagine their output (tracking information, burn-down charts, etc.) as the real artifacts and these two items as ongoing activities (like Product Backlog grooming) or part of the Scrum events (part of Sprint Review and Daily Scrum).
1. Product Backlog
The Product Backlog is an ordered list of everything that might be needed in the final product of the project, in other words parts of the expected final product (a wishlist). All items are described in simple business language (non-technical) and all of them are presentable to every stakeholder. Every requirement and every change in the project will be reflected in the Product Backlog.
The Product Backlog is dynamically changing and improving; it is never complete. We do not wait until the Product Backlog is complete to start delivering the items; the first Sprint can be started as soon as the Product Backlog has a sufficient number of stories
defined.
The Product Owner sets a number of factors to determine the value of each item for the business. Return on investment is usually one of the factors. All these factors will be summarized into one value (importance) and this is shown with each item.
The Product Backlog items will then be ordered based on their value, in a way that the higher an item is, the sooner it will be delivered by the Development Team. As the items located at top of the Product Backlog will be delivered sooner, they will also be more detailed and clear compared to the lower items.
The next figure shows a sample set of Product Backlog items presented in a number of cards.
The Product Backlog is an ordered list of items (stories)
Each Product Backlog item also has a work estimate. These estimates are solely done by the Development Team, and are used in comparison to the capacity of the Development Team in a single Sprint, to determine the number of items that will be selected for that certain Sprint. Additional information might be added to each item to help the Scrum Team take control.
This figure shows the type of information available for a single Product Backlog item in a typical Scrum tool. This is also a good example of a Scrum tool.
Take your time to study this diagram as it contains a lot of information. These are the different parts of this dialog box:
- Story Name – “The Fourth Sample Story” in this figure.
- Story Description – It is useful to store all the relevant information here, so that the whole Scrum Team can have access to it.
- Alerts – Optional custom alerts can be set here.
- Due Date – You can add optional custom due dates and use them to track stories. For example, you have decided in the middle of the Sprint (part of the detailed planning) to finish a certain story in a particular date, and you set that date here.
- Complexity – It is a field used to define the nature of the story and can be used for Sprint Planning. Usually the more complex a story is, the more uncertain its estimate would be.
- Estimate – The estimated volume of the story determined by the Development Team.
- Categories – When there are lots of stories in the backlog, it is a good idea to categorize them for ease of access and maintenance. This can act as a normal WBS (work breakdown structure) in traditional projects where deliverables are grouped together.
- Assignments – The story can be assigned to any person in the team. However, the whole Scrum Team would remain accountable for it.
- Tracker – You can record time spend on each story for further analysis, refining estimates, billing, etc.
- Colors – You can set different colors to each story to differentiate them visually in the Scrum board. This is another way of grouping/categorizing items.
- Tasks – You can breakdown the story into tasks (detailed planning) and track them separately. A simple progress would be calculated for each story based on the number of completed tasks. Tasks are created by the Development Team.
- Change Log – The history of the changes made in this story (such as creation of tasks) would be stored to be used later.
- Attachments – You can attach relevant documents and use the software as a document management tool.
- Comments – Each member of the Scrum Team can leave comments and collaborate with others. This field is very helpful and we always ask team members to use it.
- Additional fields – If all of the above fields are not enough for you, you can define your own custom fields and use them for other planning and control needs.
One important use of Scrum tools is collaboration. Collaboration features are more important when the Scrum Team is not co-located and traditional ways of collaboration are not possible.
The following figure shows a sample Product Backlog created in an online Scrum tool. The Product Owner has identified the stories, but the estimates are not done yet (question marks on the right side of the rows).
Current status of the sample:
- Identified stories – yes
- Estimates – no
- Sprint plan – no
- Tasks – no
- Completed tasks and stories – no
The Scrum Team should add details, estimates, and order to the Product Backlog items all the way through the project, which is called Product Backlog grooming. It should not consume more than 10% of the time of the Development Team.
The Product Backlog is created more based on discussion rather than documentation. The Product Backlog items (aka stories) should be easy to understand for non-technical stakeholders.
The following figure shows the sample Scrum tool after the addition of the estimates. Current status of the sample:
- Identified stories – yes
- Estimates – yes
- Sprint plan – no
- Tasks – no
- Completed tasks and stories – no
The total amount of work in this sample is shown to be 234 points. It is common to break the large stories (such as the tenth story in the sample which is estimated 100 points) into two or more stories later.
Sometimes multiple Scrum Teams work on the same project. The Product Backlog is a representation of the scope of the final product and therefore, there should be only one Product Backlog, no matter how many Scrum Teams are working on the project.
2. Sprint Backlog
The Sprint Backlog is created during the Sprint Planning event which is the first event in a sprint. During the Sprint Planning event, the Scrum Team collaborates on creating the Sprint Backlog, which consists of the following:
- A number of items selected from the top of the Product Backlog, based on their estimated work and the estimated capacity of the Development Team
- The Sprint Goal, which will help describe the real meaning of the items and direct the efforts of the Development Team
- A detailed plan for delivery of the items and realization of the Sprint Goal during the Sprint
The Sprint Backlog is frozen after the Sprint Planning and the Development Team will focus on delivering an Increment of “Done” based on this plan. The statement “the Sprint Backlog is frozen” means that items (stories) in the Sprint Backlog cannot be added or removed during the Sprint. However, it might be necessary to get more information, justify, or clear some of the items during the Sprint, which should be done in the presence of the Product Owner. The detailed plan which is normally not complete at the end of the Sprint Planning will become more complete as the Sprint continues.
The following figure shows the sample project in Sprint Planning time: a new Sprint, called “The First Sprint” is defined with start and end dates, and Scrum Team are now ready to select items from the top of the Product Backlog to be assigned to this Sprint.
Current status of the sample:
- Identified stories – yes
- Estimates – yes
- Sprint plan – on-going
- Tasks – no
- Completed tasks and stories – no
Suppose that the estimated capacity of the Sprints is 50 points. In this case, all we can choose for the Sprint is shown in the next figure.
Current status of the sample:
- Identified stories – yes
- Estimates – yes
- Sprint plan – almost finished
- Tasks – no
- Completed tasks and stories – no
Now we have four items with an estimate of 44 points. We cannot add the next Product Backlog item, because it has 40 points and we only have about 6 points free in our Sprint capacity. It is common for the Product Owner in such cases to reorder the backlog; for example to bring The Sixth Sample Story above The Fifth Sample Story, and so we can add it to the Sprint Backlog (next figure).
Current status of the sample:
- Identified stories – yes
- Estimates – yes
- Sprint plan – yes
- Tasks – no
- Completed tasks and stories – no
The next figure shows the Sprint items, along with a summary, and a burn-down chart. Current status of the sample:
- Identified stories – yes
- Estimates – yes
- Sprint plan – yes
- Tasks – no
- Completed tasks and stories – no
This screen acts like a dashboard and we can use it to plan and track the items. In the next figure for example, some of the items from the top of the list are broken down into tasks. Most Scrum tools are equipped with collaborative features, which are especially useful for remote teams (adding comments and sharing ideas for example).
Current status of the sample:
- Identified stories yes
- Estimates yes
- Sprint plan yes
- Tasks yes (only for some stories)
- Completed tasks and stories no
As we go through the Sprint, some tasks and items get Done and more items are detailed. Current status of the sample:
- Identified stories – yes
- Estimates – yes
- Sprint plan – yes
- Tasks – yes
- Completed tasks and stories – yes (some of them)
The Scrum tools usually update the burn-down chart as we progress through the Sprint.
3. Increment
An Increment is a sum of all completed Product Backlog items at the end of a Sprint. Each Increment must be “Done”, and must be releasable. The Product Owner may or may not release a certain Increment, but it should be releasable (shippable).
The next figure shows how the number of stories in the Product Backlog decreases Sprint by Sprint, as the number of features in the Increments increases.
Note that the Increment concept is cumulative: each Increment also contains the features of the previous ones.
Definition of Done
There should be a shared understanding of what it means for a piece of work to be “Done”. This definition of “Done” must be discussed and agreed upon by the Scrum Team at the beginning of the project so that future Increments would be releasable.
When multiple Scrum Teams are working on a single project, it might not be possible to use the same definition of “Done” for all teams, because they might be working on items of different natures. In such a case, each Scrum Team will define its own definition of “Done” and delivers its items based on that definition. However, the integration of those definitions of “Done” should be capable of creating a potentially releasable Increment in the project level.
5. Monitoring Progress Towards a Goal
Up to now, we have used the burn-down chart to visualize the progress of development during a Sprint. You can also use a burn-down chart to visualize the progress of the whole project and this is called the project burn-down chart.
The Product Owner is responsible to monitor the progress of the whole project toward its goal. This should be done at least once per Sprint Review. The Product Owner determines the amount of remaining work and compares it to the remaining work of the previous Sprints, and forecasts the completion date of the project. All stakeholders should have access to this information.
The project burn-down chart shows the amount of remaining work, instead of the amount of completed work; therefore, the line for actual performance goes downward as we proceed and the faster it goes down, the happier we will be!
The vertical axis (remaining work) shows the amount of work (which is a sum of all the estimates for each item in the Product Backlog), and the horizontal axis shows the amount of time passed from the beginning of the project or the number of Sprints passed.
We usually add another line to present the uniform distribution of the volume of the work across the initially estimated number of sprints. This line acts as our planned progress, and will be used to compare to our actual values.
In the above chart, we can expect the project to be completed earlier than initially planned.
Monitoring Sprint Progress
Besides the monitoring done for the whole project, we should also monitor the progress of each single Sprint throughout its life. This is the responsibility of the Development Team and should be done at least once per Daily Scrum.
This information is used to calculate the likelihood of achieving the Sprint Goal and completing all items of the Sprint Backlog.
The Sprint progress information can be represented by a burn-down chart, and this chart can be a part of the Sprint board, where everyone can see.