Product Increment

The word “Increment” itself describes its nature to increase to the next level. The Increment is a forward step towards a goal or vision.

What is PI?

The Product Increment is the summation of overall backlog items finished during the Sprint and also the previous completed Sprints. At the end of each Sprint, it should be a working product to move into the production phase to go live. That means it should be in a usable stage and meet the Scrum team’s definition of “Done”.

The Increment should be ready for use regardless of the product owner who decides it. The most important final Artifact in the Scrum framework is the actual Product Increment.

What is the purpose of Product Increment(PI)

The Scrum team is responsible for deciding what they need that can be considered as an Increment. This may significantly vary for the Scrum teams, but the team members must have knowledge in sharing of what work they have to complete. It is used to estimate when the work will get completed on Product Increment. This helps you in guiding the team members in picking the product backlog items during the sprint planning session. The Development team is responsible for the product. The purpose of every Sprint is to deliver the working software product.
The objective of the scrum process is to deliver quality in such a way that the product is in a ‘done’ state at the end of every iteration, so it could be released, delivered to clients for early feedback, or used as a tool for testing. While it is compulsory for an organization to deliver the shippable product according to the schedule of the Scrum process, this allows the product to be a part of the repeated process of development, evaluation, testing, and innovation that Scrum inspires.

For teams practicing Scrum, the production site might always reflect the recent work completed by the team members during continuous iterations. In these cases, the app or public site will be the final product increment. The outcome of the Sprint is the Product Increment with a usable software product owned by the Product Owner. The Sprint Review is the input given to the Increment for delivery of the shippable product.

Who will deliver a Product Increment?

Product Increment will be delivered by the development team on a regular basis, that reflects the Product Owner’s Roadmap, supports the Vision and meets the team’s Definition of Done.

Challenges involved in delivering Product Increments

The development team should be cross-functional in order to deliver the Product Increment. Supporting the increment delivery across the organizational silos during the sprint is a big challenge for organizations adopting Scrum. In general, individuals, through their local work practices will exhibit the actual values of the organization irrespective of the espoused values. Having individual performance evaluations that strengthen local silo-based practices will strive against this cross-functional work and will hold back the development team in delivering the Product Increment.
When an organization or a team has the potential to deliver Product Increments, there will be some new forces in the organization which include:

• Changes to the “iron triangle” or the “triple constraint”. As the Sprint length is fixed, the time is also fixed, so cost and scope must be altered to support this change.
• There will be no late delivery.
• It becomes easier to report on delivery i.e whether the increment is Done or not.
• Internal silos that stop the development of Product Increment will begin to decline as the team works cross-functionally.\

How to create a Product Increment?

0All the essential activities such as analysis, design, build, integration, and testing will be performed by the team during the sprint to create a working Product Increment (partially, not completely) as shown in the figure below. This combined approach has the advantage of validating the assumptions rapidly that are made when creating product features. In Scrum, we generally work on one feature at a time, but not in a phase. So, we will be creating a valuable Product Increment by the end of a sprint (only a few but not the complete product features). That increment should be integrated and tested with all the earlier developed features or else it is not considered as done.
For instance, the features of increment 1 should be included in increment 2 as illustrated in the above figure. This gives us feedback on the recently developed features within the context of already developed features and also helps us to view the product more in-depth than we might otherwise have.

We get feedback on the sprint results, which enables us to adapt. We can decide which features to work on in the upcoming sprint or change the process of building the next set of features. Sometimes, we might see that the increment is not as great as it could be. In such cases, we can plan to rework for a future sprint within the context of our promise to iterative development and continuous improvement. Scrum doesn’t want us to define a fixed set of iterations. The continuous flow of feedback will direct us to do the significant and effective number of iterations while building up the product incrementally.

What is the outcome of the Product Increment?

The Product Increment is advantageous to all the Scrum project roles. The stakeholders and the Product Owner can assess the current ROI from the functionality that is attainable by the customer at each sprint end. Also, the team’s unity develops along with the product functionality in every sprint, as they deliver potentially shippable code from the promises they made in the sprint planning meeting as a team.