 | Product Breakdown (“Artifacts”) |
With the Product Vision well-defined and the right people assigned to the right roles, it is the Product Owner’s job to break the product into “build-sized” pieces, or Stories: the smallest buildable units of the product. These stories are then placed on the Product Backlog & Sprint Backlog, and collectively, as the stories get built, they come to represent a Product Increment.
Product Backlog
The master list of all items, (usually Stories) that still need to be built for the final product to be complete. It is organized in order of build priority, with most essential, urgent, or strategic items coming first.
Sprint Backlog
Select Stories from the Product Backlog set to be built within the next build cycle, or Sprint. Collectively, they represent what the PO believes are most essential for the next stage of product release, and what the Dev Team believes they can realistically build within the time allotted for the sprint.
Product Increment
The collection of all items completed by the end of a given sprint, including the value of all items completed in previous sprints. It represents the current state of the product, which can be assessed in terms of quality and “done-ness”. An increment should be a releasable state of the product.
Why “Artifacts”?
A Scrum artifact, analogous to its generic definition (an object crafted by a human being), is …
something that can be examined & assessed for quality and completeness.
They exist in Scrum to allow for a visible, tangible state of the product at all levels–
- the stories themselves,
- the execution of the stories in sprints, and
- the overall product.
They can be empirically critiqued on all levels, as well, allowing for a transparent, honest assessment of
- whether the items are well-defined,
- whether the build is on course, and
- whether the product is emerging as something of optimal value.