Quality in Scrum — DoD

Quality means doing it right when no-one is looking
- Henry Ford

The notion of quality in development is always a touchy subject, there are advocates everywhere for everything. In Scrum there is one “simple”(ish) concept which is as follows

The ability of the completed product / deliverable to meet the Acceptance criteria and achieve the business value expected by the customer.

Each role in Scrum contributes to the quality of the overall product in different ways.

The Product Owner

Maximizes the value delivered by the scrum team by keeping the most pertinent backlog for the client / stakeholders

The Scrum Master

Accompanies the organization in adopting scrum and facilitates the work of the scrum team by removing impediments to achieving the sprint goal. Basically, they make sure everyone understands how scrum works and that the developers can concentrate on what they do best

The Developers

Integrate the notion of quality by adhering to a definition of done…

If you finish your User Story correctly then in theory value is delivered. The difficulty is in knowing when your User Story is finished. The 2020 Scrum guide lays a lot of responsability on the usage of a definition of done (defined at an organization level). But what should go in the definition of done? If it is too vague then potential problems go slip through into the code. If there aren’t enough tests, you could break your application. Yet, if your definition of done is much too complicated, then your team may only complete one User Story per sprint.

Compare the following Definitions of Done

1. Coding standards are respected in the code
2. Unit tests are completed
3. Data fixtures are updated
4. E2E tests are updated
5. Integration tests are updated
6. The development answers the whole task
7. Acceptance tests are completed
8. The ticket is deployed on the testing server
9. The developer makes sure that the ticket is testable
10. The code has been reviewed and validated by at least another developer
11. If there are specific actions needed to correctly deploy the ticket, documentation is created for the next scheduled production deployment
12. The acceptance test procedure is written in the ticket
13. All necessary documentation is updated

Pretty comprehensive right!?
Now compare with the the following DoD

1. Development tasks finished
2. UX reviewed
3. QA tasks finished
4. Tested
5. No tech debt

The first DoD was created (and not implemented) by my team when there were 5 backend devs , 1 devops and 1 front (me). It wasn’t implemented as we still have a lot of legacy maintenance to do which means that it would be almost impossible to get anything done. We basically left it in a cupboard (Confluence) and forgot about it, saying we needed a more comprehensive Definition of Ready (it’s not our fault it’s the Product Owner’s… Responsibility in Scrum).

The team has since undergone huge changes, there is now only 1 backend dev and me on front…

I watched a really interesting webinar at Atlassian by Joyce Pang Vargas who is a scrum master at Atlassian. She demonstrated how they use various tools during their sprints, including a definition of done which is included in the description of every ticket. The simplified DoD above is from that presentation.

What I really liked was the idea that if a developer finds an issue that may create some tech debt, the team swarms around the issue so that when the ticket is resolved, there is no tech debt associated with it. (Even though every line of code is potentially tech debt later on…). Each ticket / story is developed by at least 2 developers, which means the knowledge is shared and the solution is probably more innovative. Joyce touched on the issue that the DoD is purposefully short so that her team can actually deliver some value during the sprint instead of getting bogged down by an over complicated DoD.

Conclusion?

My team has yet to agree on a global DoD (yep, for legacy maintenance too), as we are currently using a different working method to Scrum due to covid and the loss of a lot of colleagues. We plan to come back to scrum and implement our DoD and will try and use a simplified version. If we find that doesn’t work… inspection then adaptation. A great piece of advice I got recently off Tanner Wortham (www.spikesandstories.com) is try stuff and learn quickly.