The Increment is one of three artefacts in Scrum.
When work taken on by the team achieves the Definition of Done, then it becomes an Increment.
An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.
Work cannot be considered part of an Increment unless it meets the Definition of Done.
When work meets the Definition of Done and becomes an Increment, its Story Points are added to the team’s velocity.
Work that isn’t done returns to the Product Backlog at the end of the Sprint to be re-prioritised by the Product Owner. There is no “partial credit” for Story Points as these are not a measure of effort expended. Velocity is a measure of what can be delivered to Done in a single Sprint, not “effort points”.
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
The moment a Product Backlog item meets the Definition of Done, an Increment is born.
The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.
If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.
The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.
1. Schwaber, K. and Sutherland, J. (2020) The Scrum Guide. The Definitive Guide to Scrum: The Rules of the Game.
2. Hodgson, M. R. & Horrigan, M. B. (2021) Agile Essentials.
How do you write great User Stories?
What are flow and value metrics and why should you make the change from project management metrics ?
A stakeholder suddenly claims it doesn’t work as intended and therefore it’s a bug that requires immediate attention. What do you do? How do you treat bugs and incidents and change requests in agile teams?
There are many traditional times you can engage users – gathering requirements and user acceptance testing. What are the best times to engage users when you’re in an agile team?
Teams love to get credit for their efforts, but is that what you should do if a User Story gets 1/2 way there but doesn’t get to Done in the Sprint? What should you really do with the remainder of the work?
Why do traditional, waterfall style projects fail? Some claim its a requirements problem and point to the need for more planning, user research, and design. The truth is we’re not looking at the problem the right way and complex environments require a different way to collecting information and delivering using that knowledge.
Copyright © Zen Ex Machina® and ™ (2021). All rights reserved. ABN 93 153 194 220