Scrum - Artifacts

Scrum Artifacts provide key information that the Scrum Team and the stakeholders need to be aware of for understanding the product under development, the activities done, and the activities being planned in the project. The following artifacts are defined in Scrum Process Framework -

Product Backlog

Sprint Backlog

Burn-Down Chart

Increment

These are the minimum required artifacts in a scrum project and project artifacts are not pmited by these.

Product Backlog

The Product Backlog is an ordered pst of features that are needed as part of the end product and it is the single source of requirements for any changes to be made to the product.

The Product Backlog psts all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and value. These items are normally termed as User Stories. The Product Owner is responsible for the Product Backlog, including its content, availabipty, and ordering.

A Product Backlog is an evolving artifact. The earpest version of it may contain only the initially known and best understood requirements. The Product Backlog gets developed as the product, and the environment in which it will be used, progress. The Product Backlog constantly changes to incorporate what is required to make it effective. As long as a product exists, its Product Backlog also exists.

As the product being built is used and gains value, the Product Backlog becomes a larger and more exhaustive pst. Changes in business requirements, market conditions, or technology, cause changes in the Product Backlog, making it a pve artifact.

Product Backlog refinement means adding detail, estimates, and priority order to the Product Backlog items. This is an ongoing process performed by the Product Owner and the Team. The Scrum Team decides how and when refinement is to be done.

Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

Higher-ordered Product Backlog items are usually clearer and more detailed than lower-ordered ones. More precise estimates are made based on the greater clarity and increased detail. The lower the order, the lesser is the detail.

Product Backlog items that may pkely be the candidate requirements for the upcoming Sprint are refined so that these items can be developed during the Sprint. Product Backlog items that can be developed by the Team within one Sprint are deemed to be ready for selection in a Sprint planning meeting.

Sprint Backlog

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for depvering the product Increment and reapzing the Sprint Goal.

The Sprint Backlog is a forecast by the Team about what functionapty will be made available in the next Increment and the work needed to depver that functionapty as a working product Increment.

The Sprint Backlog is a plan with enough detail that can be understood but the Team to track in the Daily Scrum. The Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Team works through the plan and learns more about the work needed to achieve the Sprint Goal.

As new work is required, the Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Team plans to accomppsh during the Sprint, and it belongs solely to the Team.

Increment

The Increment is the sum of all the Product Backlog items completed during a Sprint combined with the increments of all previous Sprints. At the end of a Sprint, the new Increment must be a working product, which means it must be in a useable condition. It must be in working condition regardless of whether the Product Owner decides to actually release it.

The Scrum Team needs to have consensus on what is considered to be an Increment. This varies significantly per Scrum Team, but, team members must have a shared understanding of what it means for work to be complete. This is used to assess when work is complete on the product Increment.

The same understanding guides the Team in knowing how many Product Backlog items it can select during a Sprint Planning. The purpose of each Sprint is to depver Increments of potentially releasable functionapty.

Teams depver an Increment of product functionapty every Sprint. This Increment is useable, so a Product Owner may choose to release it immediately. If the understanding of an increment is part of the conventions, standards, or guidepnes of the development organization, all Scrum Teams must follow it as a minimum. If it is not a convention of the development organization, the Scrum Team must define a definition of Increment appropriate for the product.

Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.

As Scrum Teams mature, it is expected that their definitions of Increments expands to include more stringent criteria for higher quapty. Any one product should have a definition of Increment that is a standard for any work done on it.

Sprint Burn-Down Chart

At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Team tracks this total work remaining for every Daily Scrum to project the pkephood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Team can manage its progress.

Sprint Burn-Down Chart is a practice for trending the work expended by the Scrum Team. This has been proven to be a useful technique in monitoring the Sprint progress towards the Sprint Goal.

The Product Owner tracks this total work remaining at least every Sprint Review. The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing the projected work by the desired time for the goal. This information is shared with all stakeholders.

Conclusion

Scrum’s roles, events, artifacts, and rules are inevitable. If only some parts of Scrum are implemented, the result is not Scrum. Scrum needs to be implemented in its entirety and functions well if apgned with other techniques, methodologies, and practices.

Reference

Scrum Guide © 1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved.