Scrum’s artifacts represent work or value and are designed to maximise transparency of key information.
Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured.
There are three artifacts:
- The Product Backlog
- The Sprint Backlog
- Increment
The Product Backlog contains items that help progress towards the Product Goal and is managed by the Product Owner. The Sprint Backlog is contains all of the items that are being worked on during the Sprint and progress towards the Spring Goal.
These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.
A Scrum Master can detect incomplete transparency by inspecting the artifacts, sensing patters, listening to what is being discussed, and detecting differences between what is expected and what is delivered. It is the Scrum Master's role to work with the Scrum Team and the organisation to increase the transparency of artifacts. Those who are performing the work and those inspecting the delivered result must share a common definition on what 'Done' is.
The Scrum artifacts must be inspected frequently to detect undesirable variances or problems. Inspection enables adaption and ensures any problems are deterred early.
The Product Backlog
The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its:
- Content
- Availability
- Ordering
Other members of the Scrum Team, including the Developers, have the ability to access the Product Backlog and can add items to it, but it's the responsibility of the Product Owner to manage it and ensure enough content is included.
The order chosen for the items in the backlog is coordinated by the Product Owner. This will usually be the highest priority and most detailed ones at the top of the list with the lower priority and less detailed ones at the bottom.
The earliest development of the Product Backlog lays out the initially known and best-understood requirements, but expect those requirements to change during development or when new information is discovered.
The Product Backlog evolves as the product and the environment in which it will be used evolves. It is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. If a product exists, its Product Backlog also exists.
The Product Backlog lists the following items that constitute the changes to be made to the product in future releases:
- Features
- Functions
- Requirements
- Enhancements
- Fixes
Each item in the Product Backlog will have the attributes of a:
- Description (details about the item)
- Order (a priority order; high, medium, low)
- Estimate (story points to estimate the time and effort to complete)
- Value (a measure or representation of how valuable the item is)
Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.
Product Backlog Refinement
Products Backlog Refinement is an ongoing process in which the Product Owner, who has the vision for the product, and the Developers, who creates the product, get together and collaborate on the product details and the backlog items. It is the act of reviewing and revising items by breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. The highest priority items at the top, especially in software like Jira, so that they're ready to be selected and pulled up into the next sprint.
Product Backlog items that can be completed by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Refinement usually consumes no more than 10% of the capacity of the Developers
The Developers who will be doing the work are responsible for the estimation. The Product Owner may influence the Developers by helping them understand and select trade-offs.
Note: a Product Backlog Refinement is NOT a Scrum event. It is a meeting that is used to enable transparency and ensure tickets are correctly configured before they are added to a Sprint.
Commitment: Product Goal
The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfil the Product Goal.
A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.
The Product Goal is the long-term objective for the Scrum Team. They must fulfil (or abandon) one objective before taking on the next.
Extra: Definition of 'Done'
The Definition of 'Done' is the criteria that must be met for an item to be deemed as completed. The Scrum Guides 2020 defines it as:
A formal description of the state of the increment when it meets the quality measures required for the product.
Try and keep the Definition of 'Done' clear and concise, testable and measurable, and realistic.
The important points to know are:
Everybody must understand and agree what 'Done' means.
That includes everybody in the Scrum Team and everybody in the other Scrum Teams if multiple scrum teams are working on the same product release.
Remember, the goal of the Sprint is to produce a potentially releasable increment, and every increment is an additive to all the prior increments, so the increment needs to be able to successfully integrate with the product (as well as be tested successfully). Therefore, integration should be one of the elements that define the definition of done.
Definition of 'Done' expands due to maturity
As the Scrum Team matures through the Sprint Retrospectives and continuous improvement, you would expect to see expectations for their Definitions of 'Done' expanding to include more stringent criteria for higher quality increments. And because the Definition of 'Done' is improving over time, the later work items are going to be of higher quality than the previous ones.
This may mean that when you look back at the work items that have been done previously in previous sprints, you may look at these increments and improve them to meet the current Definition of 'Done'. This is what's known as 'taking on development debt'
The Definition of 'Done' must be followed as a minimum
If the Definition of 'Done' for an increment is part of the convention's standards or guidelines of the organisation, all Scrum Teams must follow it as a minimum.
If 'Done' for an increment is not defined by the organisation, then it is up to the Scrum Team to define the Definition of 'Done' that is appropriate for the product.
Strictly speaking, as far as Scrum is concerned, you cannot add any extra items to the Definition of 'Done' until the Sprint is finished. Otherwise, you would effectively be moving the goalposts and could upset the Developers.
However, you would consider changes in the Sprint Review and also the Sprint Retrospective to make sure that any extra standards for the Definition of 'Done' would be added for future sprints.
The way you manage this is to add new items to the Product Backlog, which will cover those extra definitions of done.
Example of Definition of Done
Your standard Definition of 'Done', which will be applied to all work items, might include things like:
- Testing, including integration testing
- Adequate documentation
- Policies, legislation, best practices met
- Organisation conventions, standards or guidelines met
- Security standards
- Usability standards
- Scalability standards
- Performance standards
An website example could look as follows:
- Styles meet the style guide
- Images optimised for web
- Spell checked and proofread
- Code peer reviewed
- Accessibility standards met
- Performance and stress tested
- Architecture best practices met
- Process documents updated
The Sprint Backlog
The Sprint Backlog is made up of the work items from the Product Backlog that have been chosen to be completed in the current Sprint via the Sprint Planning session. This decision will have been made by the Scrum Team.
The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).
The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.
Remember, the Sprint needs to complete at least one increment so the items in the Sprint Backlog become a plan for delivering that Product Increment and realising the Sprint Goal. It is also a forecast by the Developers as to what functionality will be in the next Increment and the work that needs to be completed in order to deliver that functionality into a done Increment.
By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. To ensure continuous improvement, it is helpful to include the most helpful improvements identified in the previous retrospective meeting.
But what if, once the Sprint has started, you find that other work items need to be completed in order to realise the Sprint Goal. Are you allowed to add work items to the Sprint Backlog now that the Sprint has commenced? The answer is yes, but only if you are one of the Developers.
It's quite common through working on the Sprint Goal that you'll find some unforeseen work that needs to be completed in order to realise the goal, so that work needs to be made transparent and added to the Sprint Backlog. Just remember to add the appropriate detail into it and put in an as accurate as possible estimation on effort and time.
It also goes the other way. If any work is now deemed unnecessary, that can be removed, and as work is done and completed, it will get moved into the done pile.
And through all these changes, the majority of which will be completed work, the estimation of how much work is left in order to complete the Sprint should be reducing.
The Daily Scrum meeting is an opportunity for everyone to get together and discuss the Sprint Backlog as well as communicate their progression and any impediments. The emergence of new items coming into the Sprint will be discussed in this meeting too.
Commitment: Sprint Goal
The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.
The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog. As the Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.
Increment
An Increment is a concrete stepping stone/an item towards the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.
Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.
Work cannot be considered part of an Increment unless it meets the Definition of Done.
Commitment: Definition of Done
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
The moment a Product Backlog item meets the Definition of Done, an Increment is born.
The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.
Don't fall into the habit of waiting until the Sprint Review to release a new increment; if it is ready to be released, then go ahead and release it.
An Increment must meet the Definition of 'Done'. If the Definition of 'Done' for an increment is part of the standards of the organisation, all Scrum Teams must follow it as a minimum. If it is not an organisational standard, the Scrum Team must create a Definition of 'Done' appropriate for the product.
The Developers are required to conform to the Definition of 'Done'. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of 'Done'.
