Listen to this post
Note: This is a continuation of the post, Using Cost of Delay to Improve Scrum
Teams new to Scrum face many common challenges.
- Not finishing stories at the end of a sprint because too many have been opened
- Too many untested stories at the end of a sprint
- Doing an analysis sprint, design sprint, coding sprint, testing sprint (“Scrumerfall”)
- Separation of coding and testing responsibilities
- After the demo, realizing there were misunderstood requirements
In an earlier post, I discussed how attending to the cost of delay helps us focus on removing delays in workflow, feedback, communication, and error detection. This involves a focus on finishing (not starting a new story if you can help somebody else with an existing story), working on small stories, and using test-first methods.
Review that list of challenges. Each of these challenges show up as impediments at the end of a sprint. Each can be avoided, or at least mitigated, by following the guidance of removing delays by focusing on lowering the cost of delay.
No longer will you be removing impediments after they’ve been discovered. Now, you will remove them before you even hit them!