What Scrum Master should do to prevent out of time constraints (time-boxes) of events?

Question

Scrum has strict limitations of events in time. It is hard to stay in the events time-boxes that Scrum Guide prescribes.

What Scrum Master should do to avoid situation when Scrum Team didn't reach a goal of event in time?

I am interesting about four Scrum events (Daily Scrum, Sprint Planning, Sprint Review, Sprint Retrospective) and Product Backlog refinement activity (which have no time-box, but have limit of Team capacity).

Answer 1

Before I get into the answers you should know that to me it sounds like the real root cause here is you don't have a good scrum master. Your scrum master should be able to handle most of these issues - and it sounds like they are not stepping up and coaching the team on how to improve their process. That said - here are my responses to each of your questions:

1. The ScrumMaster needs to help keeps each members update short and concise. If a conversation starts happening between the devs just say 'lets discuss after stand' or 'park it', then write it on a post-it and stick it on the wall. If members consistently get into too much detail bring it up in retro and make it a goal for next sprint to time each stand (maybe limit time per person) to help drive them to be concise.
2. For a month long sprint a full day should be plenty of time (I do 2 week sprints and planning takes a little under 2 hours). The key thing to making planning go faster is to have grooming meeting during the actual sprint for the NEXT sprint. This gets stories into shape, questions answered, and sets up the next planning meeting to go much faster.
3. Not sure if you are doing this already, but you might want to separate the demo from the sprint review/other activities. Again, time box it, set a time limit for each item, and when discussions start to erupt just say 'lets talk offline' or something.
4. You need to have a retro goal before you go into retro meeting. Pick a theme or topic, and try to focus discussion around that instead of trying to tackle everything at once. Come out of the meeting with tangible action items that are assigned to team members with a due date.
5. This is a totally normal problem to have. It sounds like your backlog is a little rough, so plan on reduced capacity for a bit while your team grooms that backlog. This will totally pay off in the end and will help address point #2.

Answer 2

Jagg provides some good guidance on mechanics of improvement. Let me see if I can address a little of what to do now.

1- You didn't fail, you found ways that didn't work. Find the Thomas Edison quote "I didn't fail 1000 times, I found a 1000 ways it didn't work" in a nice format online. Print it and post it in the team area.

2- Don't kick yourself. This isn't easy to do. Right now you're in what we call the "Shu" phase. You know what the Scrum rules are and you're trying to hold to them. This is good, keep trying. Just don't kick yourself if you fail. See #3.

3- Start asking "What can we do to get better?" Instead of "we failed" move forward to "now what". Go back to Jagg's post for adivce here.

4- Shorten the Sprint. It seems highly counter intuitive, it works. Shorter sprints means there is less to do. Think of it this way, you have 30 stories in your month long backlog, that's 30 opportunities for your grooming or planning to go down the rabbit hole. If you're sprints are two weeks, you only have 15 stories. Your odds of a rabbit hole just dropped in half.

5- Good agenda planning. One of the big curses of any meeting is the lack of good agenda planning. A Daily Standup even has an agenda. That agenda is "Team Member 1, three questions. Team Member 2, three questions."

For Daily Standup, you can even go as far as divde 15 minutes by the number of team members and set a timer. Timer goes off, you move on. Remember, Standup is quick, any discussions go to the "follow up" pile.

For longer meetings, the secret sauce for agendas is to do your agenda by clock time, not minutes.

Do: 1:00 - Start 1:03 - Agenda review 1:05 - Agenda Item one 1:30 - Agenda Item two 1:50 - Action Item review 2:00 - Close

Don't: 5 minutes - Agenda 25 minutes - Agenda Item one etc.

Again, set a timer if you need to. If you have 4 hours labeled as "Sprint Planning" you won't ever get everything done. Figure out what needs to be done and how much time it needs. Create the agenda, send out the agenda before the meeting, post the agenda on a white board or easel paper where everyone can see it.

Cheers...

Answer 3

As your team continues to try to observe the limit of the time box they will learn how to do it. If you are trying to play the role of their problem solver, and you are the scrum master, that is not your role. Your role is to point out that they didn't observe the box, and to facilitate discussion about why and what can they do differently next time to make it work. That way they, not you, will own the problem. And they will learn how to think about their problems in ways that they don't yet know even though you do. If you're a former (or current) engineer, you'll have to learn to restrain your desire to fix things. As a scrum master you are now a coach.