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.

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.

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 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.

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.