Relation between DOD, increments and increment additivity in the new Scrum Guide
Hi everyone,
I have the following issue understanding the relationship between DOD, increments and additivity of increments as described in the new Scrum Guide (2020). First of all three statements from the Guide:
- Each increment is additive to prior increments and all increments must work together
- To provide value, the increment must be usable
- An increment is born, once the product backlog item meets the DOD
What if i have for example an product backlog item which meets the DOD (so a new increment is born), but does not work together with all prior increments? Is this even possible or should the DOD in this case be adapted in order to prevent this case? Is such an increment even considered to be usable or is it just an unusable increment not providing value? Based on the second bullet point my assumption would be that there can be unusable increments, but they just do not provide value.
What are your ideas regarding the example?
Thank you and greetings.
Why would a Definition of Done reflect anything less than the condition of being fully integrated and immediately usable?
That was an assumption i had that the DOD contains the requirement for the product to be fully usable. Anyway i am unsure about if it must be explicitly stated in the DOD that the product must be fully usable or if it is implicitly contained in the DOD when using a DOD in Scrum context.
In my opinion it does not really make sense to write this requirement down as it is kind of "obvious" that the product must be fully usable at any time. Is it still a best practice for the DOD to contain such a requirement or should it just be assumed by the Scrum Team without the need to write it down?
It may not be entirely helpful to state in the DOD that the product must be fully usable. At worst it might be considered an informal logical fallacy to do so (cf. ignoratio elenchi) in as much as it fails to establish how the objective -- full usability -- would be established.
Each sprint should create at least one functional and potentially releasable increment.
This means that if your sprint only has one PBI, and this is the first sprint, then that PBI obviously needs to fulfill the increments criteria.
Each PBI should provide business value; however, business value isnt always a feature or function.
In my view, once the first sprint timebox expires and results in a functional and potentially releasable increment, the next sprint may have PBIs that simply change the look of a UI, or add telemetry, or improve a team process. Now, if only those PBIs were completed and other feature PBIs hadnt met the DoD by the timebox for sprint 2 expires, then sprint 2 would still have a functional and potentially releasable increment because sprint 2 built upon sprint 1's increment.
What if i have for example an product backlog item which meets the DOD (so a new increment is born), but does not work together with all prior increments? Is this even possible or should the DOD in this case be adapted in order to prevent this case?
Let me add to your "What if". What if that increment is the start of a brand new feature for the product? Yes it is possible that it might now work with previous increments but it shouldn't be a common occurrence. And I would even say that in my addition, I would expect that the increment would be integrated in some way even if that is at the data level.
I would argue that any work someone would consider done will be usable in some way. Otherwise why call it done? That usability may not include direct interaction by a user and may instead be usable by another portion of code.