Scrum artifacts

Scrum Artifacts, Scrum commitments, Product backlog, Sprint backlog, Product goal, Sprint goal, Increment, Definition of Done

Product Backlog Scrum artifact

Product backlog is the single source of product requirements, a dynamic list of work to be done ordered based on value, which is constantly evolving, changing and adapting as more is learned about the product and the environment. It lists all the features, functions, requirements, enhancements and fixes designated for the next releases, while the Product backlog items have description, order, estimate, value and test description. The Product Owner is responsible for the Product Backlog, including its content, availability and ordering. Product Backlog Prioritization is done based on risk, business value, dependencies, size and date needed. The developers are estimating the effort required for each product backlog item.

Product Goal Scrum commitment

The Product Goal is a long-term objective for the Scrum team that 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 and the rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.

Sprint Backlog Scrum artifact

Sprint backlog is the list of product backlog items selected for a Sprint and the plan for delivering the increment and realizing the Sprint Goal. It is a forecast made by the developers regarding what functionality will be in the next done increment and it includes at least one high priority process improvement item from the previous Retrospective. The developers are managing and modifying the Sprint backlog during the Sprint as more is learned about the work needed to achieve the Sprint Goal, adding new required work or removing items deemed unnecessary, thus making the Sprint backlog a dynamic and highly visible artifact.

Sprint Goal Scrum commitment

The sprint goal is the objective set for the sprint that can be met through the implementation of product backlog items selected for the upcoming sprint. It provides guidance for the team on why it is building the increment, gives the team some flexibility regarding the functionality implemented and helps to deliver one coherent function with the selected product backlog items.

Increment Scrum artifact

An Increment is a concrete stepping stone toward the Product Goal that provides value by being usable for the customer. Multiple Increments may be created within a Sprint and the sum of the Increments is presented at the Sprint Review thus supporting empiricism. A product increment is composed of what was previously built, plus anything new that was just finished in the latest sprint, all integrated, tested and ready to be delivered or deployed. By releasing working software at the end of each Sprint, the customer can provide feedback that can be used to improve the product and it also ensures that the Scrum team is progressing towards delivering the final product.

Definition of Done Scrum commitment

Definition of Done is an agreed upon list of the activities deemed necessary to get a product increment, usually represented by a user story, to a done state by the end of a sprint. Definition of Done represents the organization’s formal definition of quality for all the product backlog items and expresses what the organization requires before it can deliver a product backlog item to the end user. The DoD is decided upfront, along with acceptance tests and can be shared across a group of common user stories or defined specifically for unique ones. Done means that the feature has been developed, tested, it meets all the required acceptance tests and could be shipped to a customer. The Product Owner officially accepts done features back from the team at the Sprint Review.

Definition of Ready

Definition of Ready is a clear criteria that a user story must meet before being accepted into an upcoming sprint. Although it might be very useful, especially for teams that are starting the Scrum journey, Definition of Ready should not be treated very strictly, as it might enforce Waterfall practices. DoR is typically based on the INVEST principle, having the user story independent, negotiable, valuable, estimable, small and testable. For the user story to be ready, it has to be defined clearly enough that all team members understand what must be done, it includes a clear statement of resulting business value that allows the Product Owner to prioritize and is free from external dependencies that must be done first in order to complete the story.

Scrum