Controlled Cliff Dives during Sprint Execution
As a Scrum Master/Team Coach, I think it's crucial that you conduct a mid-sprint check-in during the execution of a Sprint. I generally conduct this exercise in the middle of the sprint or when coming back from extended time-off (e.g., holiday weekends). I do this so that I can help the team to get refocused on specific goals.
I break out the burndown report to start the conversation.
Is this accurate? Are there stories that haven't been updated?
Are there stories that can be closed by end of day?
Are there stories that can be closed in the next 48 hours?
I use the term "cliff dive" to describe the burndown chart when several stories will be completed at the end of the sprint. So, the burndown looks as though it plateaus for 7-8 days and drops off at the end of the sprint when work is completed. While I think it is best to complete work earlier in the sprint to avoid closing all the work last minute, there are situations where coordination and timing might make it difficult to avoid delivery late in the sprint.
In those circumstances, here are some of the questions I ask to "control" the cliff dive.
Has quality been considered?
What steps are we taking to ensure that QA is fully engaged?
What communication do we have in place to ensure great collaboration (e.g., hand-off, working sessions, etc.).
How do we keep the developer engaged so that we minimize context switching?
These are just a few questions that I ask to spark discussions and minimize risk.`