I’ve talked about how Scrum leads to efficient, high performance teams a few times before and I’ve shared what organizations need to do to embrace agile development and Scrum. But today I want to discuss something near and dear to my heart: the immense importance of your daily Scrum practices. Land these daily Scrum routines and you’ll be sure to rock your next sprint.
Always Be on Time
One of the biggest problems we tackle with our clients is the culture of meetings starting late. It may sound simple, but a fundamental success factor for the Scrum framework is ensuring that ceremonies start precisely on time. This keeps the development team focused as much as possible on completing the work in the sprint and avoids complaints of “wasting time in meetings.”
Because Scrum relies on efficiency to meet its shorter timeframes, you simply don’t have time to waste. If a seven-person team waits around ten minutes before starting their daily Scrum, that’s an hour and ten minutes of productivity wasted. From just one occurrence! If this happens every day over the course of a two-week sprint… that’s eleven hours and forty minutes of lost time.
How many user stories would that leave incomplete?
Here are a couple of tips on how to create a culture where team members are consistently on time.
- Start each ceremony on time
At Ascendle, we’re religious about always starting on time. Our rule is that we start the Scrum ceremony precisely on time. We use https://www.time.gov/ to avoid the “My computer clock was two minutes slow” excuse.
Extreme? We don’t think so. After all, consider this: if you start a 15-minute daily Scrum four minutes late… that’s more than 25% of the meeting duration. - Impose a late penalty
Scrum teams are focused on results. So how do you battle that seemingly innocuous five minutes of chitchat before a meeting starts? By imposing a late penalty. Your team will decide on its own what their late penalties should be. Some of the penalties I’ve seen implemented are:
-
- $1 toward the pizza/beer fund. A dollar is placed into the “penalty jar” that the ScrumMaster brings along to each Scrum ceremony.
- $1 per minute that you’re late. That really drives home the importance of productivity.
- Sing a song of the team’s choice for 10 seconds.
- Do 10 push-ups. Or 10 somethings that no one really wants to do.
I know it sounds funny. And, quite often, it is. But it drives home a point and because of that, it works.
Follow the Structure of the Daily Scrum
The daily Scrum is the cornerstone for any successful sprint. Here are a few tips to land with your teams:
- The daily Scrum should last no more than fifteen minutes.
- Only the development team may speak; others may attend or observe but may not participate in discussions.
- Each development team member provides an update on what they’ve done since the last standup, what they plan to accomplish before the next one, and what impediments are in their way.
- Avoid getting into long discussion about a particular issue and instead defer these discussions to the parking lot – read more about this below.
Leverage the Sprint Burndown Chart
The sprint burndown chart is a built-in “health meter” for your sprint. It should be reviewed every day, usually towards the end of your daily Scrum. What the burndown chart shows is a line representing the current hours of work remaining compared to a target burndown line.
If your total hours are tracking with your burndown line, the sprint is on track and the development team is on schedule to deliver on their commitment.
If your total hours are tracking below your burndown line, it means your sprint is ahead of schedule. If things continue that way, they may be able to pull in some additional work.
If your total hours are tracking above your burndown line, it means your sprint is behind schedule. Some sort of course correction will be needed. Obviously, the earlier you identify this, the better – which is why the burndown chart is addressed every day.
Example of a sprint burndown chart showing a team behind schedule. Courtesy of Jira Software.
Sprint burndown charts can be generated easily with tools such as JIRA or even in a spreadsheet such as Microsoft Excel.
Utilize the Parking Lot
Sometimes issues are brought up during the daily Scrum. Since there typically isn’t enough time during the ceremony to resolve these issues, our teams use a “parking lot” strategy. Anything that needs further discussion is noted by the ScrumMaster during the team member updates and placed in the parking lot list.
At the end of the standup, the ScrumMaster announces that the parking lot is open. Anyone not required for those parking lot issues may leave. This prevents your daily Scrums from getting derailed, and it also prevents members from “hanging around” through additional discussions where they aren’t really needed.
Drive Accountability
This is another daily Scrum practice that I’m separating here because it’s important. Daily Scrums are not about the team reporting to the ScrumMaster, the product owner, or anyone else – it’s to report their progress to each other. Most importantly, it’s to form a plan for what each of them is going to accomplish before the next daily Scrum.
Procrastination is a natural human tendency that has derailed many a project. By committing to single-day goals, and with accountability driven by peers rather than managers, Scrum team members are more likely to achieve those goals and less likely to procrastinate on them.
Another thing to consider during your sprint planning process is using one-day subtasks. Keeping your subtasks to one day (or less) makes it easier to track your progress over the course of a sprint. It also makes it easier to assess the amount of work remaining. One-day subtasks on our teams are typically a maximum of four hours. This is because the average productivity for an eight-hour day is about six hours, when taking “other work stuff” into account such as keeping up with e-mail and other duties not related to work on the Scrum team. Given a 50% margin of error in their estimates, most four-hour subtasks should be completed in a single day.
As teams grow more efficient, their margins of error trend down while their productivity trends up – allowing them to commit to more work. The number of hours you use on subtasks may vary based on the type of work you’re doing, but I suggest shooting for a maximum size of “about one working day.”
Watch for Warning Signs
The sprint burndown chart is one of the best warning signs that a sprint is getting off track. But there are other signs which the ScrumMaster – or any other team member – can watch for. Some of these are:
- When subtasks labeled In progress or To verify on your sprint board have no team member’s name. Ask for a volunteer to take ownership of any unclaimed subtasks.
- When a subtask appears stuck. If the team feels the current owner needs help, they should move that discussion to the parking lot.
- When a development team member has no subtasks with their name on them. Unless they’re unavailable that day, everyone on the development team should have at least one subtask to work on. Sometimes a member is unsure how to help a project move forward and needs guidance from the team.
- When subtasks in the “Done” column of your sprint task board still show hours remaining. Not zeroing out those hours throws off the lines of your burndown chart and makes it inaccurate.
Attack Impediments
If Scrum development teams are to deliver results, they need impediments aggressively cleared from their path. These impediments are identified during daily Scrums and it’s the responsibility of the ScrumMaster to ensure their resolutions.
ScrumMasters themselves might not have the authority to clear them out of the way, but they should use their connections – and the support of project sponsors and champions – to ensure things get resolved.
When a subtask is impeded, it should be flagged in some way – in Jira it’s as easy as right-clicking on the task and hitting Add flag. Often the ScrumMaster will assign the subtask to herself to indicate she is handling the impediment, releasing the developer to work on something else.
