Scrum Artifacts Overview

The term “Artifact” in archaeology refers to an object made by a human being. The word artifact roughly translates to ‘The Work of Art’. So, artifacts are nothing but the documents we make either in a tool to get a solution to our problem or art of work that inspires to resolve.

What is Scrum Artifact?

The Scrum Artifacts provide the key information to the Scrum team members and Stakeholders regarding how the product is developed and activities to be done, and what activities are being planned in the project.

3 Artifacts of Scrum:

1. The Product Backlog
2. The Sprint Backlog
3. The Product Increment

Let’s have a brief discussion of each of the Scrum Artifacts defined in the Scrum process framework.

1. The Product Backlog

The Product Backlog is arranged in an ordered list of prioritized features that are needed as a part of the end product. It is the main source of requirements to update or include that gets reflected on the product. The Product Backlog is a highly visible artifact at the heart of the Scrum framework that is accessible for all the projects.

2. The Sprint Backlog

The Sprint Backlog consists of a list of tasks that the Scrum team has to accomplish by the end of the Sprint. During the Sprint planning meeting, the Scrum team selects priority items set by the Product Owner from the product backlog list items, usually in the form of user stories. The Sprint Backlog is a planned process contains complete information that helps to understand the changes done in the development clearly during the Daily Scrum. These Sprint Backlog items are modified by the development team during the Sprint.

3. The Product Increment

The word “Increment” itself describes its essence to increase to the next level. The Increment is a step towards a goal or vision. The Product Increment is composed of a list of Product Backlog items completed during the Sprint and also with the previous Sprints. By the end of Sprint, each backlog item must be completed in conformance with the Scrum team specified by the definition-of-done checklist.

Now, let’s deep dive into the Product Backlog artifact:

The Product Backlog consists of a list of features, requirements, functions, enhancements, and fixes that represent the changes to be done in the next product release. The Product Backlog items represent the characteristics of a description, estimation, value, and order. These Backlog items are known as “User Stories”. The User Stories are also referred to as the Use Cases. The Product Owner(PO) is the one who is responsible for the Backlog items to prioritize the requirements based on the market value and customers’ feedback.

Good Signs of a Product Backlog:

1. It is an important active document that consists of all the ‘wishlists of the users’ that are collected in the Product Backlog.
2. The Product Owner ensures that the content of the Product Backlog i.e. “user stories” or use cases should be defined in a detailed way.
3. User stories in the Product Backlog should have a particular fixed length to fit in the Sprint.
4. Each user story consists of its attributes as a condition of satisfying the acceptance criteria and use case scenarios.
5. The product backlog items also include the test description that makes to prove its completeness of definition of ‘Done’.
6. The product backlog acts as an input to the Sprint backlog in functionality.
7. This product backlog defines what to be implemented next from the nature of the user story.
   

Who are All Responsible for Creating the Product Backlog?

The Product Owner is responsible to maintain and create the product backlog. He/she re-orders the list of items in product backlog according to the priority. The team members or individuals may also suggest features to include in the product backlog list, but the Product Owner has to make the decision regarding the list of all the items whether to include or not.

Creating a Product Backlog:

The product backlog contains a list of user stories with highly prioritized items of the functionality. The Product Owner collects the data from the Stakeholder to build the project and would start preparing the user stories to reach the target. The focus is to recognize and define the user requirements.

The user story is the best way of customers’ needs for the project. The user stories are very easy to create if the given structure/format is followed-

“As <type of user> I want < some goal > so that < some reason >”

Example of User Stories:

As a power user, I can specify folders to backup based on file size, date created and date modified.

An important element in developing the Product Backlog is to understand the requirements of the user or stakeholder. Suppose if the Product Owner is not sure about the needs of a Stakeholder. He/she should begin communicating with the people and request for the solutions they need.

In many situations, they should have discussions with the Stakeholders to give their valuable suggestions. He/she should have a meeting with the technical team and members of the company to provide more inputs.

Follow a Few Steps to Create the Product Backlog:

1. Think of yourself as a customer to understand the requirements of the user.
2. Simple and easy to begin, note down everything that comes to your mind and request for the inputs.
3. Recognize everyone who are a distinct user (logged in/out, staff, admin, contributors, stakeholders, etc.)
4. Assign a business value to the user stories to understand its importance to the organization. For instance, logging might be a top priority and marked as very high, while rating an article is marked as very low as it might be a less priority one.
5. Adjust priorities whenever there are new requirements available.
6. Return to the Product Backlog continuously for grooming(add, delete, re-prioritize)
   

Techniques for Effective Product Backlog Management

The product backlog items are ordered linearly and prioritized based on DIVE criteria. DIVE represents in the following way.

1. Dependencies
   We make few dependencies in a linear way with user stories, themes or epics. Even we can have horizontal dependencies.
   
   
2. Insures against the risk causes
   It protects against risks from both business and technical.
   a. Business Value
   b. Estimated Effort
   
   A product backlog can consist of hundreds of work items, hence the acronym DEEP exists. The acronym DEEP is an interesting word for capturing the essence of the logical structure of the product backlog.
   
   
3. Detailed appropriately
   Work items mentioned in the product backlog are specified at an appropriate detailed level.
   
   
4. Estimated
   User stories are prioritized and estimated appropriately.
   
   
5. Emergent
   The product backlog is not freezing or static; it emerges on a continuing process in response to the product feedback, and updating according to the market values, and competitive. New backlog items are added, and existing items are groomed (refined, revised) or deleted or re-prioritized.
   
   
6. Prioritized
   In the product backlog, all the items are ranked as per the priority they build to create the project output. The user stories in the product backlog should completely satisfy the INVEST criteria. Hence, it is a well-known English word, as well as an acronym coined by “Bill Wake”. The word INVEST represents important traits of work items needed to be involved in the coming sprint backlog.
   
   
7. Independent
   In the specification level, the user stories are independent; they offer different functionalities, and the user stories should not overlapped.
   
   
8. Negotiable
   User stories in the next sprint are always subject to negotiations and checks of the product with a Product Owner.
   
   
9. Valuable
   Each user story in the next iteration should deliver value or benefit to the customers or the development team.
   
   
10. Estimable
    The Product Owner should always be able to estimate the size of a user story with its fixed length. A user story should not be too long as it will not fix in the next iteration that becomes a useless plan/prioritize.
    
    
11. Sized
    Each story should be small enough to complete and delivered in a single sprint. The letter ‘S’ can be taken to be sized appropriately to meet the Sprint weeks.
    
    
12. Testable
    Each user story should have clear information or specifications to develop all the possible test cases from the acceptance criteria.