Although Scrum can operate on with one to four week sprints, most organizations currently choose a one or two week duration for their sprints. This limits how long a team can take to make decisions, since with only five or ten days in the sprint, taking a day or two to organize a meeting to discuss the decision will impact delivery.
Some common failures that I have seen include:
- Team members letting an open Pull Request sit around for a day or more because they are too busy to review the changes in the PR
- Developers not immediately merging approved Pull Requests so the changes are delayed getting to the test environment
- Database changes that impact a few tables needing to be discussed with the DBA who is not available until later in the week
- Defects reported by testers sitting waiting for a developer to have the time to review report
All of the above are examples of extra time incurred in the process of taking an item from the backlog and moving it to the Done state. This increases the likelihood that there will be a rush to complete items at the end of the sprint, or that the overall sprint goal will not be met.
The fix I see for this is to build slack into the sprint so that the team is not busy all the time. Aiming for 100% utilization always leads to queuing and delays, so the team has to build in appropriate slack time to prevent decision delays.
Note. Martin Fowler has a possible fix for delays caused by the Pull Requests needing reviews.