Scrum Framework – Artifacts that Matter

What are artifacts? Well if we roughly translate the Latin roots of the word, it translates to “Work of Art”. Artifacts can be understood as something that we create. It could be something like a tool that can be used to solve a problem. In the context of Scrum, we work with three fundamental artifacts necessary to deliver a Scrum project effectively.

1. Prioritized?Product Backlog

The Product Owner develops a Prioritized Product Backlog which contains a prioritized list of business and project requirements written in the form of Epic(s), which are high-level User Stories. The Prioritized Product Backlog is based on three primary factors: value, risk or uncertainty, and dependencies. It also encompasses all Approved Changes that can be appropriately prioritized in the Prioritized Product Backlog.

1. Value—It is the Product Owner’s responsibility to ensure the delivery of those products that provide the highest level of business value first. Even an extremely valuable product may not be part of the first release if there are other products of even higher value that are sufficient for a first release.
2. Risk and Uncertainty—The more uncertainty that exists, the riskier the project is. Therefore, it is important that riskier products in the Prioritized Product Backlog are given higher priority. Products carrying a higher level of risk will also require risk mitigation actions. When these risk mitigation actions are prioritized against the backlog, the result is a Risk Adjusted Product Backlog.
3. Dependencies—It is usually not possible to create a Prioritized Product Backlog in which there are no dependencies between User Stories. Functional requirements often depend on other functional and even non-functional requirements. These dependencies can impact how the User Stories in the Prioritized Product Backlog are prioritized.
4. Estimates—High-level estimates for Epic(s) are also available in the Prioritized Product Backlog.
5. Sprint Backlog

The list of the tasks to be executed by the Scrum Team in the upcoming Sprint is called the Sprint Backlog. It is common practice that the Sprint Backlog is represented on a Scrumboard or task board, which provides a constantly visible depiction of the status of the User Stories in the backlog. Also included in the Sprint Backlog are any risks associated with the various tasks. Any mitigating activities to address the identified risks would also be included as tasks in the Sprint Backlog.

Once the Sprint Backlog is finalized and committed to by the Scrum Team, new User Stories should not be added; however, tasks that might have been missed or overlooked from the committed User Stories may need to be added. If new requirements arise during a Sprint, they will be added to the overall Prioritized Product Backlog and included in a future Sprint.

1. The Sprint Deliverables and Definition of Done

Done Criteria are a set of rules that are applicable to all User Stories. A clear definition of Done is critical because it removes ambiguity from requirements and helps the team adhere to mandatory quality norms.

At the end of each Sprint, a product increment or deliverable is completed. The deliverable should possess all features and functionality defined in the User Stories included in the Sprint and should have been tested successfully.