What comes to your mind when you think of the word ‘artifact’? Something old and of archaeological interest? While that is what an artifact means in the English language, when it comes to Scrum it has a whole different meaning. In this ready reckoner for Scrum artifacts, we attempt to look at the scrum artifacts list and how each of the artifacts helps a team to work better and add more value.
Agile scrum artifacts are information that a scrum team and stakeholders use to detail the product being developed, actions to produce it, and the actions performed during the project—Atlassian Agile Coach
Scrum artifacts aim to promote the core scrum attributes of transparency, inspection, and adaption. These artifacts, which are important primary tools for every scrum team, provide metadata points that help teams, stakeholders and others get an insight into the performance and progress of the sprint.
In order to manage work, Scrum uses three artifacts, which are Product Backlog, Sprint Backlog and Product Increment.
The product backlog is an ever-evolving artifact. It is an ordered list of all the features and characteristics that the product being developed needs. The product backlog contains a list of not just new features but also contains changes made to existing features, fixes, testing to be carried out, changes in infrastructure and more.
The Product Backlog is the responsibility of the Product Owner. The amount of work to be undertaken in a sprint is estimated by refining the product backlog. Product backlog refinement is the practice of breaking down the items listed in the backlog into smaller and definite items, in the form of user stories. As items are broken down more details may be added regarding the size, order etc.
The backlog also contains the product goal, which is the future state of the project and serves as a benchmark for the team to plan its activities around how to reach the product goal.
The sprint backlog is different from a product backlog and is an ordered list of things that need to be completed in the duration of the sprint. The items on this list are selected at the time of the sprint planning meeting. The team selects user stories from the backlog and identifies the collaterals that may be necessary to complete the particular user story. The number of hours that each task may require are also estimated. The team selects the items and size of the sprint backlog. The sprint backlog must be updated to reflect any new information that may be available.
This new information could be a result of change in the number of tasks, if too few or too many tasks were pulled during the planning stage. The team may add tasks or remove tasks to ensure that the right amount of work is being done.
Each sprint has an end goal and this is a product increment that is potentially shippable or releasable. Each increment is considered to be potentially releasable if it meets the requisite “definition of done”—a set of mutually agreed upon items or standards that a completed task or user story must reflect.
So, a potentially releasable product increment should be well tested, meet quality standards and is complete. The whole idea of Scrum is to release a potentially shippable product to the customer every few weeks and this is the premise of the potentially releasable product.
There are many other Scrum artifacts besides the three mentioned above that have to be included in sprints to enable smooth working and for tracking progress.
Defining the product vision is not just the primary stage in product development but also the most critical. The product vision is a quick summary that defines the final product to be built. It tells the team the goal, how it should be built, what solutions it should offer and who the end users of the product will be. The vision should also communicate how the product will align to the organizational goals.
The product vision is created by the Product Owner in consultation with stakeholders. The vision statement may be a little unclear in the early stages but soon builds into a ready reference for the team as it outlines the product goals and milestones that need to delivered.
This is a high-level objective that defines the goal that needs to be achieved at the end of the sprint. This shared goal is defined by the entire team and everyone works towards reaching the objective. The sprint goal should be defined by considering why it is being carried out in the current sprint and what benefit it would add to the overall product. This gives the team direction and a purpose to achieve the goal. The sprint goal is an activity undertaken during sprint planning, by the developers. The product owner may give them some direction on how it should align to the overall product goal.
The Sprint goal benefits the overall development by:
This is nothing but the acceptance criteria that is common to each potentially releasable increment. In Scrum, it is important as it helps the team decide if a user story is actually completed and if the product that they are releasing is adding value to the product and the stakeholder. Some of the commonly used criteria that define the definition of done include bug fixes, technical tasks, features etc. Besides these criteria that may be specific to the product, team and even sprints, the story must also undergo a code review, should be tested, should be immediately deployable and of a high quality.
Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable--Scrum Guide
Scrum follows the iterative and incremental approach to product development. A sprint may have multiple increments and they are presented at the time of sprint review. Developers should ensure that an increment meets the definition of done and must be releasable. But the decision on whether to release it or not depends on the Product Owner.
“A burndown chart shows the amount of work that has been completed in an epic or sprint, and the total work remaining. Burndown charts are used to predict your team's likelihood of completing their work in the time available. They're also great for keeping the team aware of any scope creep that occurs.”—Atlassian Agile Coach
This important metric helps the team and others involved in the project to visually measure the amount of work completed in a day against the projected rate of completion for the existing sprint or release. Looking at the burndown chart, a team can estimate whether they will meet the sprint goal and adjust their work accordingly.
Scrum artifacts help to:
But in order to get the most of your Scrum artifacts you need to follow certain guidelines.
Trust your artifacts and embrace them. Encourage your team to do the same. Help everyone in the team understand what each artifact stands for, its purpose and how it should be used and maintained.
If you are a Product Owner or a Scrum Master , then you as a leader should ensure that your team members are following Scrum values and principles and this includes proper use of Scrum artifacts. This is especially true if you are heading a team that is not familiar with Scrum. Make sure that everyone knows about the Scrum methodology and how to use it to deliver maximum value.
There are several organizational and Scrum management tools that are now available, which come with a host of features to improve the way we work and communicate. Embracing these tools will empower teams to efficiently use Scrum artifacts like product backlog, sprint backlog, burndown charts etc and speed up work and deliver value.
Maintaining Scrum artifacts are essential for the progress of the project and to ensure project success. The right leader can ensure that Scrum values and principles are followed during product development and Scrum artifacts are used in a way that enhances value delivery. Every Scrum team member must be aware of the Scrum artifacts list and how each artifact should be used to ensure completion of project milestones.