Search
  • Tim Burns

Taking back Scrum - Defects Over Stories

Updated: Apr 24



I describe myself as a reluctant Scrum enthusiast. Scrum is a great agile tool if you recognize it as a feature lifecycle process and not a hard and fixed process. Two concepts I like to introduce to make Scrum better

  • Zero Defects

  • Five Whys

Things I dislike about Scrum

  • No changes are made that would endanger the Sprint Goal;

  • Retrospectives

A lot of Agilists view these two as sacrosanct but as a developer, no changes disempowers the developer to deliver the most value.


Why do I feel it is agile to throw these out?


Individuals and Interactions over Processes and Tools.

That applies to Scrum because Scrum is a tool. When a developer finds a defect in the sprint, the defect work takes precedence over any stories in the sprint. As a product owner, it's important to know this. If the product owner doesn't know it, then it's up to the scrum master to correct them.


Per the scrum guide:


During the Sprint: - No changes are made that would endanger the Sprint Goal

Nope. A defect should take precedence, and it is the Product Owner's job to recognize this and adjust the plan accordingly.


Additionally, it's rare to have a sprint retrospective that is more than scrum team navel-gazing. I find the retrospective excruciating, especially the kind most scrum masters use with the "What went well," "What didn't go well." Even worse is the retrospective where you review story points as if that is some valid metric of success.


Fix the changes component with a Zero Defects Policy. Zero defects mean that the only level of acceptable defects is zero. Anytime a customer finds behavior in the feature that isn't what we intended, fixing that defect automatically precedes any work on the sprint.


Additionally, we have a 5 why's meeting to discuss 5 why's on how that defect ended up in a released version of the feature. The 5 why's meeting is a better take on retrospectives because it does what retrospectives should do - focus on the root cause analysis and fixing the root causes into why a feature did not meet the customer's expectations.


A great lecture on the principle of Zero Defects.





14 views0 comments