Dictionary.com defines an artifact as:
an object made by a human being
SCRUM artifacts are of vital importance as they help to share or "radiate" information. For this reason, artifacts in SCRUM are sometimes considered "radiators" of information.
SCRUM artifacts include:
A product backlog is a living document, which means it changes and gets updated as the team learns more, as market conditions change, as competitors bring out new products, and as customers give input into what they need.
For each item in the product backlog, you should add some additional information:
Order (as in the priority order within the whole backlog list)
Value to the business
Adding to the Backlog
The Product Owner is responsible for capturing the needs of all stakeholders within the backlog. If members the sales, marketing, legal, support teams, etc. have desired product changes or improvements, the Product Owner will first listen, seek to understand these requests, and then add items to the backlog to represent these improvements or fixes.
It is important that the stakeholders feel they are listened to. For that reason, the backlog should be somewhere where other people in the organization can see it (and can see that their observation has been captured!).
The Product Owner will also add to the product backlog when he or she receives ideas from the development team or customers, as well as from doing competitive analysis
Although the product backlog will always be added to, it is important to also edit (to groom) the items that are already in there. This means a periodical review which serves to identify, among other things, whether:
Some backlog items are no longer necessary
The estimates have changed for some backlog items
The intended outcome for an item was achieved by another feature
A particular problem has been fixed
It is also important to write specifications prepare documentation and assets for upcoming items on the backlog. For example, if the SCRUM team is working on Sprint 10, then the Product Owner is making sure the documentation and assets for any backlog items planned for Sprint 11 are being readied. In this way, the Product Owner works "a sprint ahead" of the team members.
After the sprint planning, the team has committed to a developed plan to work on a chosen set of items in the next sprint.
Those items are then removed from the product backlog and moved into the sprint backlog. The sprint backlog is guided by the sprint goal (which is the stated outcome objective of the sprint).
As the sprint evolves, it is possible that slight changes to the sprint backlog will occur. A new understanding of the feature the team is working on 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.
A burndown chart is a graphical representation of the amount of estimated remaining work. Typically the chart will feature the amount of remaining work (perhaps in hours) on the vertical axis with time along the horizontal axis.
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 estimated work remaining.
After day 2, you would expect to have 160 hours of estimated work remaining.
After day 9, you would expect to have 20 hours of estimated work remaining.
After day 10, you would expect to have all work complete (0 hours of estimated work remaining).
Things don't always go exactly to plan. 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 our burndown chart:
In the chart above, the gray line represents the estimated number of hours left. You can see that this should tend to zero as the sprint comes towards its conclusion.
The blue line is the reality: the actual hours left. This should also tend towards zero as the sprint comes to its conclusion, but the line bounces around a bit to reflect the variability of each days' actual remaining work.
You can easily create a burndown chart using a variety of software, including JIRA or even Excel (see the tutorial below):
The most important artifact is the actual product improvements, or in other words, the new code which has been written to enhance the features or usability of your product.
When a sprint ends, the team should have produced "potentially shippable code." Of course, the Product Owner may decide not to release for a few days/weeks/months, but she could release if she wanted to. Each sprint adds to the product. Therefore, the aggregation of all previous sprints together make up your product. When you add a new set of code from your sprint, then this new code has to combine with the existing code to work well. If your new features work well on their own but "break" some existing feature in your product, your product increment is not "potentially shippable."
Successful SCRUM teams therefore create product increments that are potentially attainable and improve the existing product by adding new features or usability that works well with the existing code.
SCRUM artifacts are of vital importance as they help to share or "radiate" information.
SCRUM artifacts include the product backlog, the sprint backlog, burndown charts, and product increments.