Scrum Artifacts
In archaeology, the term “artifact” refers to an object that was made by a human. The Latin roots of the word artifact roughly translate to “Work of Art.” So, an artifact is something that we make, either a tool that solves a problem, or a work of art that inspires us.
In Scrum, artifacts are “information radiators” and they serve to capture the shared understanding of the team at a particular point in time. Scrum describes three primary artifacts: the Product Backlog, the Sprint Backlog, and the Product Increment.
Product Backlog:
The Product backlog is an ordered list of requirements that might be needed in a product, prioritized in order which is made available by the Product Owner to the Scrum Team. it’s never complete, it only covers the known and most understood variables. The product backlog emerges and evolves over time and the Product Owner is responsible for its content and validity.
Product Backlog refinement, also popularly known as Backlog grooming, is an informal Scrum team ceremony, in which everyone in the team, including Scrum Master and Product Owner get together to ensure that work items in the backlog are relevant, useful, and each items aligns to the overall product roadmap. It is indeed more of a working workshop than a typical closed door meeting.
Typical activities during the backlog refinement are:\n\n* Reviewing the highest priority user stories on the top of the backlog\n* Ask the Product Owner clarification questions.
- Removing user stories that are no longer needed
- Creating new user stories when and if necessary
- Re-prioritizing and estimating the business value for the user stories.
- Re-define the acceptance criteria
- Estimating or re-estimating the story points for the user stories
- Re-assessing the relative priority of stories
- Breaking the epics further into user stories
- Refining user stories to prep for future sprints
- Understand the changing bigger picture of the product architecture as the backlog emerges.
Sprint Backlog
The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a "Done" Increment.
Typical activities during the Sprint planning session are:
- The Scrum Product Owner defines the Sprint Goal.
- Based on this goal the relevant entries in the Scrum Product Backlog are chosen by the Scrum Product Owner and moved to the Sprint Backlog.
- These entries are then updated and broken into smaller stories by the Scrum Team so that they can be completed within one Sprint.
Discuss any new information that may impact the plan. - Present the velocity to be used for this Sprint.
- Confirm team capacity. It’s important to iterate here that the Scrum Team defines their capacity for the upcoming Sprint and not the Product Owner.
- Confirm any currently known issues, concerns, assumptions or dependencies discovered during the planning.
- Define acceptance criteria and create testable examples.
- Review the definition of DONE and make any appropriate updates based on technology, skill, or team member changes since the last sprint
- The entries are then estimated & prioritized based on story points and business value.
The success of the sprint will later be assessed during the sprint review meeting against the sprint goal, rather than against each specific item selected from the product backlog.
Product Increment.
The Product Increment is the most important Scrum artifact, It’s the sum of all Product Backlog items completed during a Sprint and all previous Sprints. At the end of a Sprint the new Product Increment must be in a usable condition and meet the Scrum Team's Definition of Done. As a potentially shippable product increment, it is demoed to the Product Owner. The feedback from the Product Owner is appended to the Product backlog.
Scrum relies on transparency, inspection and adaptation. The choices that are made to optimize the value and control the risk to meet the standards are made in light of the state of the artifacts.
So, the project team needs to ensure the state of the artifacts by examining the difference between the desired results and the ones obtained in reality. This work usually involves continuous learning, convincing, and change. Transparency, inspection and adaptation doesn’t occur overnight, it is a journey.