 | Product Increment |
The last of the Scrum artifacts is the 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.
Definition of “Done”
“Done-ness” is a very important concept in Scrum, both on the level of a Story and of an Increment. With clear acceptance criteria, the Dev Team, and then the PO can determine that each story is complete. Only with complete stories can a scrum team act on core principles, particularly those related to empirical process control, where developed software must be …
Releasable
A scrum development team is expected to complete a potentially releasable state of the product at the end of each sprint, and it is with this in mind that stories are selected for the Scrum Backlog. If the sprint does not end with fully “done” stories, or if “done-ness” hasn’t been clearly established through the acceptance criteria, then the increment isn’t releasable. this leads to a lack of confidence in the product and trust in the team.
“Inspectable”
A sprint is planned with stories prioritized based on claims by the PO (often via stakeholders) of their effectiveness in producing a product strategic for the market and for further development. If Stories are not “done,” the product cannot be put in the hands of users who can “inspect” through interaction and give feedback on the validity of those claims.
Time-Boxed
The decision to develop each feature of a product is made based on how much value it provides versus how much the development process will cost. If features take longer than expected to produce, then they may end up costing more than their perceived value, which also calls into question the value of the team that produced them, or at least estimated the effort it would take.
Of Quality
In order for a team to release iterations at a constant rate (a core principle), they must be adding to a solid, stable code base. If that code base is of poor quality, then over time, more and more effort must be made to correct or understand it, which will slow down the development speed of the team. It will also lead to errors that will eventually come out in future releases of the product.
In all cases above, when acceptance criteria are not met, or if they were not well-specified, the very purpose of Scrum/Agile is undermined, and trust is lost in all directions.
When a product increment is well conceived and executed, it can be strategically inspected so that all parties can make important decisions about how to proceed in the next iterations of the product.
With a full understanding of all artifacts, we now turn to the ceremonies that make up the iteration process.