New Teams Can Avoid Common Errors by Understanding Cost of Delay

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.

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!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.