Scrum Artifacts – Product Increment

One of the fundamental concepts of Scrum is the team must deliver a potentially shippable increment of code each sprint. This increment must include complete slices of product features, and it must be "Done." Additionally, the increment needs to be integrated with all the increments produced in past sprints. This is a radical mindset change for anyone used to dealing with the Waterfall process. How does a project produce a potentially shippable product in a two-to-four-week sprint?

Note: "potentially shippable" does not mean it has to be deployed with all the work involved in actually releasing software, like support from logistics, marketing, product management, training tech support, printing documents and flyers, and executive oversight. The product increment enables the team to deliver products to the customer frequently, at the end of each sprint. "Potentially shippable" means the customer can see the product working as if it were released. There are no prototypes; this is actual working code. This gives the customer the opportunity to point out what is not working as expected, and to give new ideas to make the product better.

If you think about it, the product increment idea is great for all parties involved in the project. It allows direct access to customer feedback from working software without any overhead, other than the sprint review meeting. The team does not waste time dealing with code freezes, bug triage, or an end-of-game QA bug-fix cycle – and it happens at the end of each sprint. In each sprint, the team implements user stories which hold small, single-feature product slices. The Increment is the sum of all the product backlog items completed during the current sprint, and all previous sprints as well. Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together. At the end of a sprint, every feature in the Increment must meet the definition of "Done". Every feature defined as a user story must be considered done before it can be demonstrated in the product increment. This ensures the software best-practice activities like unit test, QA, integration testing, and documentation are completed before the customer can exercise the new functionality slice in the working code.

The definition of "Done" for each user story is defined and agreed upon by the Product Owner, Scrum master, and all members of the team. It is a combination of the acceptance criteria included in the user story and the best software practices required for releasing code. Without this definition of "Done" there is no way to ascertain if the work completed should be accepted into the product increment. The team uses the "Done" criteria during development to signal when a task is finished. And the definition of "Done" is used by the product manager to decide when completed work should be accepted, and thus included in the product increment. Since only done user stories gain the team the user stories' velocity points, it is an important metric to the team. If the definition of "Done" is not working for the team, it can be changed for the next sprint during the sprint retrospective.

Even though each sprint produces a potentially shippable product increment, it is not a product unless the product owner decides it's ready to release. As potentially releasable, Increments must be thoroughly tested, well-designed with good structure, and written in high-quality code with good documentation on how the user will operate the delivered features.

The product increment is valuable to all the roles in the Scrum project. The product owner and stakeholders can evaluate the current return on investment from the functionality available to the customer at the end of each sprint. And the team's cohesion grows with the functionality of the product in every sprint, as they deliver potentially shippable code from the commitments they made as a team in the sprint planning meeting.