PM Decoding #4: Three Common Pitfalls of Scrum Adaptation and How to Fix Them
Not sticking to the Definition of Done
One of the ground concepts of Scrum is not to release any work that doesn’t meet DoD. If this happens, then:
- The quality is decreased
- It becomes impossible to understand the precise amount of work completed by the team, which enables Transparency.
The Definition of Done can be adjusted every Sprint based on inspections and, then, Adaptation of the empirical data gathered from the previous iterations. The matter of changing DoD shall be raised on the Sprint Retrospective as it is one of the key topics (DoD, individuals, tools, interactions, processes) that should be discussed at the event.
All items from the Sprint Backlog that are not meeting the DoD should be moved back to the Product Backlog after Sprint is completed.
Not Implementing Retrospective Takeaways
Not being committed to improvements implementation after discussing them at the Retrospective event will not only devalue the event itself and demoralize the team but also violate the core of the Scrum framework.
The time box for the Retrospective is three hours for a one-month Sprint (for shorter Sprints, the event is usually quicker); during that time, the team can generate many improvements regarding individuals, tools, processes, interactions, and DoD.
The key is to not act on all of them simultaneously.
Three pillars of Scrum are Inspection, Adaptation, and Transparency. An inspection enables Adaptation, and without Adaptation, Inspection is considered pointless. The progress can be slow, but it needs to be there.
Therefore, try to limit the number of improvements added to the Sprint Backlog. On the Sprint Planning event, discuss the priority of each item with the team and choose only those with the highest priority. I would recommend no more than five items for the one-month Sprint.
By acting so, you enable:
- Inspection: inspecting what has to be done during the Retrospective event
- Transparency: doing work that is to be done visible by adding it to the Product Backlog and then to the Sprint Backlog
- Adaptation: adapting new processes, tools, interactions, individual behaviors, or DoD — whatever is in your scope
Confusing Acceptance Criteria with the Definition of Done
Acceptance criteria (AC) and the Definition of Done (DoD) have a lot in common — both concepts are used to ensure quality. However, while AC is different for every Product Backlog Item (PBI), the DoD is applied to all work performed during the Sprint.
Written by the Product Owner (sometimes with the help of a Quality Assurance Engineer), AC is a set of conditions that must be met for PBI to be accepted by users. Of course, these conditions differ for every PBI and vary significantly according to the initial business requirements.
Here is how PBIs are related to AC:
On the other hand, DoD is created not by an individual but by the Scrum team and is regularly adjusted to reflect the desired level of quality. DoD is usually set for the whole Increment and can’t be changed unless the Sprint is over.
Here is what the DoD can look like:
- Unit Tests are passed
- E2E Tests are passed
- Acceptance Criteria are met
- Functional requirements are met
- Non-functional requirements are met
Both concepts are essential in software development and helpful when implemented wisely.
Suggested reading connected with the topic: Acceptance test-driven development.
Check other PM Decoding Medium articles:
