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.
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.
Let’s have a brief discussion of each of the Scrum Artifacts defined in the Scrum process framework.
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.
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.
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.
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 take the decision regarding the list of all the items whether to include or not.
The product backlog contains all the 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 of 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 >”
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.
The product backlog items are ordered linearly and prioritized based on DIVE criteria. DIVE represents in the following way.
we make few dependencies in a linear way with user stories, themes or epics. Even we can have horizontal dependencies.
it protects against risks from both business and technical.
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.
work items mentioned in the product backlog are specified in an appropriate detailed level.
user stories are prioritized and estimated appropriately.
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.
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.
In the specification level, the user stories are independent; they offer different functionalities and the user stories should not be overlapped.
User stories in the next sprint are always subject to negotiations and checks the product with a Product Owner.
Each user story in the next iteration should deliver value or benefit to the customers or the development team.
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.
The 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.
Each user story should have clear information or specifications to develop all the possible test cases from the acceptance criteria.
Really helpful article about velocity! You have great stuff on this topic! Thanks for the valuable information...
Hi, is it normal or necessary for a brief record (minutes) of the meetings to be kept and logged? If so what might be a simple format for issues raised and action points?