Agile Artifacts Question Bank 

Q: What are the three Agile (Scrum) Artifacts?

Scrum’s artifacts represent work or value. They are designed to maximize transparency of key information. Thus, everyone inspecting them has the same basis for adaptation. 

The three Agile (Scrum) artifacts are as follows:

Product Backlog:  

• It is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team. It includes features, bug fixes, technical tasks, enhancements or improvements.

Sprint Backlog: 

• The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

• The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal.

• Sprint Backlog is updated throughout the Sprint as more is learned. 

• It should have enough detail that they can inspect their progress in the Daily Scrum.

Increment:

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

• Each increment should be in a state where it could be delivered to the customer if needed i.e., potentially releasable or shippable. It should be usable in order to generate value.

• An increment must meet specific quality standards, defined by the "Definition of Done," to be considered complete. 

Q: When can the Product Backlog be updated?

The Product Backlog is dynamic; it constantly changes to identify what the product needs in order to be appropriate, competitive, and useful. Product Backlog items can be updated at any time by the Product Owner or a delegate. Even if the responsibility is delegated the Product Owner remains accountable for the Product Backlog.

Q: Who creates the Definition of Done?

If the Definition of Done for an Increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.

Q: When is the Sprint Backlog created ?

The Sprint Backlog is created during the Sprint Planning meeting, which takes place at the beginning of each sprint.

This is a time-boxed event , where the Product Owner presents the prioritized product backlog items and how they map to the Product Goal. The Developers, along with the Scrum Master and Product Owner, collaboratively plan the work that will be done during the upcoming Sprint. 

During this event, the Developers choose items from the top of the Product Backlog and creates the Sprint Backlog, which is a list of the items that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.

This meeting is important because it ensures that the Developers understand what they will be working on and that they have the necessary resources and support to complete the work.

Q: When many Scrum Teams are working on a single product, what best describes the Definition of Done?

If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done to make their combined Increment valuable and useful. 

Q: What is sizing the Product Backlog item?

Sizing a product backlog item means estimating the effort required to complete a single item within a product backlog. The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs. 

There are various techniques teams may use to size their Product Backlog items such as:

Absolute: Often time-based; for example, The Product Backlog Item (PBI) will take 4 hours of work

Relative: Uses a scale that lets developers estimate the size of a PBI relative to each other. For example; story points or T-Shirt sizing (S, M, L, XL).

Right Sizing: Identifies items that are small enough to be completed within one single Sprint. For example; Developers discuss if they can complete a PBI according to their Definition of Done comfortably within one Sprint, if not they should break down the PBI into smaller more precise items.