Implementing Scrum Artifacts

By definition, the term artifact refers to any object made by humans or something that can be observed through investigations or experimentation. In the traditional model, we are used to having an untold number of potential artifacts related to a project. Many of those artifacts take the form of physical documentation and reports of various topics. However, in a generic sense, a programmer's code and database schemas are other examples of artifacts. In the traditional model, documentation is a direct result of the detailed project planning, monitoring, and control processes.

Scrum seeks to minimize the production of artifacts, and Sutherland and Schwaber limited their list of artifacts to just three. These include the Product Backlog, Sprint Backlog, and Increments. Collectively, these artifacts portray the work and value of a project and provide the means for transparency, inspection, and adaption. The goal is to keep the team's focus strictly on the most useful information necessary to manage a Scrum project effectively.

Product Backlog

The Product Backlog provides a prioritized list of all identified requirements known to the Product Owner. No matter the size of a product, there is only one Product Backlog, and it includes the entire set of requirements that have been identified for the product under development. The Product Owner is responsible for the Product Backlog, and they alone have the authority to include what's in the list and prioritize the items on the list. Yes, the Product Owner will take input from other stakeholders and executives, but only the Product Owner is held accountable for the specification and delivery of high-value and high ROI features and the functionality built into the product.

An updated Product Backlog is necessary for as long as a product remains viable and facing competitive pressures. Using the 80/20 role and ROI assessments, the Product Owner continues to direct the development team to focus on delivering the highest in the shortest time possible. Over time, as new increments of functionality are released, with new items added to the Product Backlog, the Product Owner continues to use the same 80/20 rule and ROI assessments to determine development priorities for upcoming increments.

The 80/20 rule assessments can continue for as long as the implementation of related features has a positive ROI. This rule may seem strange because, after a while, the team will be working on features well down the list in the original 80/20 assessments. But again, as long as the development activities have value and a positive ROI, the development can, and should, continue.

A Product Backlog lists all identified features, functions, business and user requirements, identified enhancements from the Sprint Reviews, and identified bug or defect fixes. The typical Product Backlog has a tabular format with five columns, specifying Name, Description, Priority, Work Estimate, and Value. Higher priority items in the backlog have more details included in their descriptions than lower priority items. There is no need to define the requirements in detail unless and until their value justifies a higher ranking.

I mentioned previously that large projects only have one Product Backlog. I also mentioned that Scrum scales through the replication of the process across small teams. As a result, large products can potentially have any number of small teams working against the single Product Backlog. In such cases, it may be useful to add another column to designate the type of work performed or the team responsible for completing the items on the list.

Product refinement is the act of updating the Product Backlog, a process that never stops for as long as the product justifies new development activities. Competitive markets, business and user needs, and available technology enhancements provide reasons to update a product, thus necessitating the refinement of the Product Backlog. Also, the need for refinement naturally occurs as low priority items make their way to the top of the list.

The Product Owner and Scrum Team collaborate on the refinement of the Product Backlog. The product development team must be involved as they alone understand the details of how to build the product, as well as the impact of developing architecture and design elements to support the functional and non-functional requirements of the product. However, the team should not get carried away with this activity. The Scrum Guide suggests that a maximum of 10% of the Scrum development team's time should be devoted to this activity.

The highest-ranked items in the Backlog that are available for selection in an upcoming Sprint must have sufficient refinement that the team has confidence that they have a complete definition of Done and that the increment of work is deliverable within the Sprint. Only the development team can estimate the work effort for each deliverable increment. The Product Owner can negotiate with the development team to define or redefine the scope of work, but that is the limit of their influence on impacting the development team's estimates.

Sprint Backlog

The Sprint Backlog includes the list of Product Backlog items selected for development in the Sprint, plus the work tasks required to build the required functionality. Through the Sprint Planning process, the development team determines the type of work as tasks necessary to create this increment of new functionality. The agreed definition of Done for each backlog item, plus the Sprint Goals, informs the development team as they define the work tasks for an upcoming Sprint.

The Sprint Backlog provides transparency about both the backlog items and the scope of work agreed upon for the Sprint. Throughout the Sprint, the development team and Product Owner, as well as other interested stakeholders, can inspect and evaluate progress against the Sprint Goal and Sprint Backlogs. When there are negative variances, the development team adapts to minimize impacts. The daily Scrum is the primary Scrum Event that provides the opportunity for transparency and the inspection of progress against the backlog.

Another essential concept is that the Sprint Backlog emerges throughout the Sprint. In other words, the development team cannot know all the variables that might impact their work. As they begin to work through the Sprint Backlog items, they gain a better understanding of the work required to deliver this new, incremental functionality. The development team updates the Sprint Backlog to ensure it accurately reflects the current scope of work identified for the increment. As the team identifies new work requirements, they add them to the Sprint Backlog. Likewise, the team removes work items from the Sprint Backlog that are no longer necessary. Only the development team has the authority to make changes to the Sprint Backlog. But as with all Scrum Artifacts, the information is transparent and available to all interested stakeholders to make sure they know about both the decisions taken and the reasons the teams made them.

Increments

An increment is a term used in Scrum to specify all the Product Backlog items included in the current Sprint. Since each Sprint builds upon previous increments, the value of the current increment builds on the value of previous increments. In other words, the benefit of the current increment is not just the value of the backlog items that were added in the current release, but also the sum of the value of all previous increments.

Each increment must stand alone as a potentially releasable product. The Product Owner will decide whether they want to release the increment are not. But the development team must ensure the increment fully incorporates the requirements of the increment, meeting all definitions of done, including the potential for releasing it to a customer.

Each increment must also contribute toward the achievement of the vision established by the Product Owner for the product. If the increment does not support the vision for the product, something has gone wrong. Either the vision is wrong, or the priorities that have been established in the backlog are inconsistent with the vision. Transparency and inspection of the increment facilitate such analysis. As the development team and the Product Owner discover such inconsistencies, through inspection, they use the process of adaption to recalibrate and realign their efforts.

At this point, you know how to construct a Scrum Team, establish the appropriate Sprint events, and gather necessary information for transparency, inspection, and adaption through the use of Scrum Artifacts. We will look at how to put all these things together to manage work associated with developing, delivering, and maintaining complex products in the next chapter, which describes the Scrum approach to development.