The 3 Scrum Artifacts in the Scrum Project

To be honest with you guys, this is the topic or area which is close to the hearts of almost all of the Scrum practitioners and the most widely discussed among the Scrum teams. Specifically, in my case, I just love taking up this topic with the people I interview. Let me take you to journey on how it got originated and what it is all about.

As per Scrum Alliance “Scrum falls within “Agile,” which is the umbrella term for several types of approaches to getting any complex, innovative scope of work done. The concept is to break large projects into smaller stages, reviewing and adapting along the way.” As per the survey was done by version one, scrum is the most popular framework being used globally. Scrum is a lightweight process framework for agile development and it distinguishes from other agile processes by explicit ideas and practices, divided into the three categories of Roles, Artifacts, and Time Boxes.

Let’s focus on the artifacts part for now and dive into further details on its components.

An artifact is a concrete by-product created in the course of product development. Scrum artifacts characterize work or value in numerous methods that are beneficial in providing transparency and prospects for inspection and adaptation. In Scrum, artifacts are “information radiators” which serve to encapsulate the shared understanding of the team at a certain point in time.

Now that we have understood the definition of it, let’s dive further and check most important scrum artifacts that are adding value to scrum.

To make it easy, a product backlog is a list of all the things that are required in the product. It is an ordered list of all features, functions, requirements, enhancements, and fixes that institute the modifications to be made to the product in upcoming releases, as in the details below:

A product backlog is a dynamic entity and hence it keeps evolving, for the teams, it is a live unit. To keep this product backlog healthy, the product owner has to make sure that the below items are in place and being closely monitored. It’s the Product Owners responsibility to build up a stack of item s in the backlog and prioritize them as per the business goals and the global approach. The product backlog is a dynamic list of items and as we call it in agile, it is ‘live document’ that should be frequently updated based on changing project requirements all the way through development.

A product roadmap is a high-level pictorial synopsis that plots out the vision and path of your product. A product roadmap connects the why and what behind what you’re building. It’s a guiding tactical document as well as a plan for executing the approach. It can get the internal participants in alignment and assist in the discussion of options and situation forecasting.

Building a product roadmap aids in communicating the path and advancement to the teams and the stakeholders. This document consists of the high-level initiatives and the plan for accomplishing the work that supports the product strategy.

Crafting a product roadmap should be a continuous process throughout the lifecycle of a product. One should gather requirements and features from a variety of sources, including customers, partners, sales, support, management, engineering, operations, and product management. It is up to the product management team to prioritize incoming ideas to make sure the roadmap aligns against the business goals.

The sprint backlog consists of all the stories or items the team committed for a particular sprint. It is a commitment from the scrum team to the stakeholders for a sprint. During the sprint planning meeting, the scrum team pulls the highest priority items from the product backlog which are usually in the form of stories. They discuss the final acceptance and zero in on the points to be allocated for the story. During this ceremony the team also creates tasks which are required to complete the stories, they drill down to the lowest level of details so that nothing is missed, to ensure quality.

According to the Scrum Guide, the Sprint Goal is an objective to be met by the Sprint through the implementation of part of the Product Backlog. The Sprint Goal helps provide focus on an objective we want to achieve and allows the flexibility to negotiate the work to achieve that objective.

The burndown is a chart that shows how quickly the team is burning the efforts to reach the completion. It shows the total effort against the amount of work we deliver each iteration. The x-axis in the chart shows the time in days and y-axis represents the total hours of work estimated in a sprint. Some of the teams use story points in the y-axis instead of total estimated efforts. Both the approaches are fine as long as the team understands the idea behind it. Its purpose is to enable that the sprint commitment is on the track to deliver the expected solution within the timeline (sprint).

“A product vision represents the core essence of its product or product line. It also sets the direction for where a product is headed or the end state for what a product will deliver in the future.” – Aha!

Your product vision should not be a plan that shows how to reach your goal. Instead, you should keep the product vision and the product strategy – the path towards the goal – separate. This enables to change your strategy while staying grounded in your vision. (This is called to pivot in Lean Startup.)

Once the scrum team has started working on the sprint backlog, there is a need to track the progress so that there are no surprises in the end. I have witnessed many teams who initially start the sprint with a lot of zeal and positivity but end up feeling frustrated due to impediments or roadblocks, they feel the hindrance in their work and hence start cribbing on the end results. It is really important to monitor the sprint progress, there are different techniques a team can use.

“The Product Increment is 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.” – Wibas. Ownership of the product increments should belong to the release engineers in most organizations and should be fully available to the product owner.

The definition of done is created by the scrum teams to make an agreement with and with the stakeholders on the getting the stories accepted. It also ensures the quality of work to be delivered by the end of the sprint. The components of “definition of done” differ from team to team.

From the above discussion, we now understand the artifacts that add value to the Scrum process. The artifacts from the base for Scrum implementation, effective use of these stated artifacts can actually help in improving the product and its delivery, and most the quality. I mentioned quality because you can define your definition of done in such a manner that it focuses on quality, even the way a user story is created is a big contributor to the quality angle.

You can learn more about Scrum artifacts through our Scrum Tutorial.

Research & References of The 3 Scrum Artifacts in the Scrum Project|A&C Accounting And Tax Services
Source

Share on Facebook

Tweet

Follow us