Increment is one of the 3 artefact defined in the Scrum Framework as per Scrum Guide 2020. It is a single source of all the work that goes into the product. It is guided by its commitment: Definition of Done. Entire Scrum Team is accountable for the Increment.
Artefacts in the Scrum are there to enable transparency. These artefacts gets inspected and adapted during Scrum Events.
Scrum has 3 Artefacts
- Product Backlog
- Sprint Backlog
- Increment
Increment is the sum of all the PBIs that meet the Definition of Done. Hence, the Increment is always growing.
We can consider this a concrete step in the direction of the Product Goal.
Accountability
Developers of the Scrum Team are responsible for creating the Increment but accountability lies with the entire Scrum Team. This suggests that there is no pointing fingers. We fail and success as a team together.
Commitment: Definition of Done
Each Scrum Artefacts has a commitment. For Increment commitment is the Definition of Done.
Definitions of Done represents quality that is required for the product to make it usable, valuable and potentially releasable.
Definition of Done supports the empirical process by providing shared understanding about the quality and completeness. It enables Scrum Team and stakeholders to inspect this quality and completeness. This inspection allows adaptation to take place.
Note: If there are multiple teams working on the same product, a common Definition of Done is essential for allowing the alignment across teams.
Key Myths & Tips
Myth 1: Many Teams believe that creating a Done increment is enough and their job is completed.
Fact: It may happen that Definition of Done doesn’t include the final release element. There can be many factors that lead to release decisions e.g. cost of acquiring release for customer. The Product Owner is responsible for this decision.
Myth 2: Scrum Teams can only release after the Sprint Review.
Fact: Release can be made as soon as the Increment is ‘Done’. Many advances teams use practices like CI/CD (Continuous Integration and Continuous Deployment) that enables release on demand which could be even multiple times during a Sprint.
Few Tips
- Include Definition of Done as part of Sprint Planning. This helps Developers plan their work better.
- Inspect & Adapt Definition of Done regularly. Sprint Retrospectives are best opportunity to discuss quality and how this quality can increased and reflected into Increment via updated Definition of Done.
- Only show the Done Increment in the Sprint Review. This will enable true feedback. Remember, undone work reduces transparency.
- It is very important that stakeholders also understand the level of quality and completeness. It is a really good practice to share the Definition of Done at Sprint Review.
