Return to site

SCRUM: When Done is Too Hard by Ian Mitchell

· scrum

☝️ The Scrum Guide demands high professionalism, with teams delivering valuable product increments in one month, and any deviation from its framework is not considered Scrum.

🤦 ‍In the field, Scrum is often loosely interpreted and customized to fit organizational contexts, resulting in deviations from its intended implementation and potentially missing out on expected benefits.

🔧 Organizational change challenges often lead to modifications of the Scrum Framework, disregarding its principles.

A key indicator of a broken Scrum implementation is the failure to meet release standards within a Sprint due to various factors like

- tooling,

- organizational issues, and

- external dependencies,

undermining process control and creating uncertainty.

👎 Widespread dysfunction in Scrum implementation has led to lowered expectations, with many accepting subpar "Done" definitions.

This compromises empirical testing and product adaptation, undermining the essence of Scrum.

🪟 Transparency is fundamental in Scrum, enabling effective inspection and adaptation.

To address issues like a release deficit, clarity is essential for teams, stakeholders, and executives involved.

🙅‍ A Development Team can refuse work if they can't complete it within the Sprint and can avoid taking on technical debt.

The Scrum values, including commitment and courage, may lead them to assert their non-Scrum status until they address the release deficit and adjust their commitments accordingly.

📉 In practice, many teams opt for "best efforts" with an inadequate Definition of Done, resulting in a release deficit.

However, maintaining transparency is vital, even if the issue can't be resolved immediately.

They can consider including the deficit in their Definition of Done and emphasize that Scrum isn't fully implemented, ensuring everyone understands the gap and its consequences.

EXAMPLE DEFINITION OF DONE

Remember, a Definition of Done applies to an increment, and it should include:

1. Environment readiness for release, ensuring no unintegrated work remains, validating the continuous integration framework, and verifying test data.

2. Completion of handover to support (unless in a DevOps context).

3. Preparation for review, including Sprint metrics and re-estimating unfinished user stories.

4. Code completeness, resolving "To Do" annotations, refactoring, unit testing, and peer reviews.

5. Completion of functional testing, both automated and manual, along with regression testing and defect resolution.

DEFICIT FOR RELEASE

"Done" criteria essential for release, not yet achievable by the team, represent a deficit, which should be listed separately (e.g., outside the Definition of Done). A deficit signifies that full Scrum implementation is lacking and suggests the presence of technical debt.

Performance, security, and user acceptance testing, as well as cross-platform functionality, must be completed.

Release authorization is required.