Scrum Artifacts
Dictionary.com defines an artifact as:
an object made by a human being
Scrum artifacts are essential as they help make important information more transparent, increase collective shared understanding, and provide something for the Scrum Team to inspect and adapt. In the case of the Increment, the artifact is high quality, usable, and adds to all previous work for the product.
There are three Scrum artifacts:
Product Backlog
Sprint Backlog
The (product) Increment
A Product Backlog is a living document, which means it changes and updates as the team learns more, market conditions change, competitors bring out new products, and customers give input into what they need.
For each item in the Product Backlog, you should add some additional information:
Description
Order (as in the priority order within the whole backlog list)
Estimate
Value to the business
Adding to the Backlog
The Product Owner is responsible for capturing the needs of all stakeholders within the Backlog. For example, suppose members of the sales, marketing, legal, and support teams, etc., have product changes or improvements. In that case, the Product Owner will first listen, seek to understand, and then add items to the Backlog to represent these improvements or fixes.
It is essential that the stakeholders feel they are heard and have input into the Product Backlog. While they give input and make requests, the Product Owner remains the sole person accountable for what the team works on and in what order. This accountability is central to the Product Owner role.
The Product Owner will also add to the Product Backlog when they receive ideas from the team, customers, or their own investigation. Anyone can contribute an idea, but the Product Owner makes all decisions regarding what goes into the product.
Backlog Refinement
Although the Product Backlog will always be added to, it is crucial to edit (refine) the items already in there. This means a periodic review that serves to identify, among other things, whether:
Some backlog items are no longer necessary.
The estimates have changed for some backlog items.
Another feature achieved the intended outcome for an item.
A particular problem has been fixed.
It is also essential to clearly state the needs, expected outcomes, and other vital information into the Product Backlog Items so the team can understand what is being asked of them. For example, if the Scrum Team is working on Sprint 10, the Product Owner ensures that the work that is likely to get planned for Sprint 11 (and possibly Sprint 12+) is being readied. In this way, the Product Owner works ahead of the team members.
After the Sprint Planning, the team commits to working on a set of items in the next Sprint.
Those items are then removed from the Product Backlog and moved into the Sprint Backlog. The Sprint Goal guides the Sprint Backlog (which is the stated outcome/objective of the Sprint).
As the Sprint evolves, slight changes to the Sprint Backlog may occur. For example, a new understanding of the feature in progress could mean that something is added to or removed from the Sprint Backlog.
The Sprint Backlog is a real-time picture of the work that the team currently plans to complete during the Sprint. It should be easily visible as stakeholders may want to keep an eye on progress.
The product improvement is the most critical artifact, or in other words, the new code that has been written to enhance the product's features or usability.
When a Sprint ends, the team should have a potentially releasable increment. Of course, the Product Owner may decide not to release for a few days/weeks/months, but they could release if they wanted to. Each Sprint adds to the product. Therefore, the aggregation of all previous Increments together with the current Increment makes up the product. When you add a new set of code from your Sprint, it must combine with the existing code to work well. Suppose your new features work well on their own but "break" some existing features in your product. In that case, your Product Increment is not "potentially releasable" and is probably of low quality or is not meeting your definition of done.
Successful Scrum Teams create Product Increments that are potentially releasable, high-quality, and valuable, which will improve the existing product by adding new features or usability that works well with the existing code.
We will look at how to define successful Product Increments in a later chapter.
A burndown chart is a graphical representation of the amount of estimated work remaining. Typically, the chart will feature the remaining work (perhaps in hours) on the vertical axis with time along the horizontal axis.
Burndown Example
Consider the following example of a two-week Sprint that has an estimate of 200 hours of work.
Before the Sprint starts, the team has estimated 200 hours of work.
After day 1, you would expect to have 180 hours of work remaining.
After day 2, you would expect to have 160 hours of work remaining.
After day 9, you would expect to have 20 hours of work remaining.
After day 10, you would expect to have all work completed (0 hours of work remaining).
Things don't always go according to plan. For example, a ten-hour task might take 12 hours. Or an eight-hour task might take one hour. So you should have a graph that tends towards zero as you move to the right. The image below represents the expected shape of a burndown chart:
You can easily create a burndown chart using a variety of software including JIRA or Excel (see the tutorial below).
Let’s Recap
Scrum artifacts are vital as they make things transparent, thus increasing empiricism and providing a foundation for inspection and adaptation.
The Product Backlog is a roadmap and holds all necessary work for the product.
The Sprint Backlog is a current plan to deliver the Sprint Goal. It is emergent, flexible, and minimally sufficient.
The Increment is the sum of all the value you create in the Sprint and all the work before it.
Scrum artifacts include the Product Backlog, Sprint Backlog, and the Increment.
Additional Resources
Backlog is defined as the full set of user stories not in the current Sprint. This represents the remainder of the project’s scope. This article provides rules and guidelines for managing and refining the backlog.
A Sprint will eventually be completed at various stages during Scrum. This concise video on using burndown charts will provide you with the elements you will need to use during the closing stages of your Sprint.
