6 ways to improve your scrum meetings

Nobody loves long meetings. Literally nobody. It’s not just that they get really boring, really fast.Even the custard creams can only keep you interested for so long. If anyone bothers to bring some. And that’s a big, hungry if. So start having scrum meetings!

Scrum meetings aren’t a new thing. Dev teams all over the world use them to power through their workload, run successful sprints and generally get stuff done. You might even be using them already. Great stuff. But unless your productivity’s through the roof and your developers are super happy bunnies, there’s always room for improvement, right? 

If you’re new to all this, here’s what we mean by scrum meetings… You get the whole dev team together for one short, sharp meeting, every day, without fail. You keep it to 15 minutes max. You stay on your feet. No sitting = no waffling.

You all take turns to answer three quick questions:

 

• What have you got done since the last scrum?
• What will you be doing before the next scrum?
• Is anything standing in your way?

 

The idea is to keep everyone in the picture, accountable and motivated.

 

Scrums are often used in sprints towards a particular product release and in that case the ‘what have you got done?’ will generally relate to the team’s overall goal, helping everyone see how they’re progressing towards it. So that’s a scrum. But what’s the best way to make yours go with a bang?

Mornings are hands-down the best time for scrum meetings. Get everyone together at the start of the day and you won’t be interrupting them in the middle of a task. They’ll be fresh, energised and able to concentrate on what everyone else is saying. 

It’s also a great time because everyone’s looking ahead at what’s in store for the day. Getting your whole team on the same page at this point means no-one’s wasting time doing duplicate work, or wrestling with a problem that’s already been solved. Everything’s clear and you’re all good to go.

So, first thing in the morning works well. But ultimately, you need to have your scrum meeting at a time that suits your team. And once it’s agreed, stick to it. Even if someone’s running five minutes late. Start. Because by the time that five minutes has turned into ten minutes, and you’ve kept five developers hanging around waiting, you’ve quickly wasted nearly an hour of hands-on dev time.

Plus, if you make an exception once, you’ll make it again and again. And before you know it, your scrum will be a loose, moveable thing that people don’t stick to or respect. So dig your heels in. Stick to your guns. It’ll soon become part of everyone’s routine.

Once you’ve got everyone there, keep to the 15-minute time limit. It’s a trust thing. People are giving you their time, and trusting you to respect it. Ask everyone their three questions, and if issues spin out of their answers, tackle those separately, individually, once the meeting’s over. Otherwise you’re pulling your whole dev team into problems they don’t need to know about.

There are some great tools you can use in order to catch up with your remote team. We like Slack’s Standuply, which uses a bot to ask your remote team members those magic three questions at the same time every day – and gathers their responses into a report you can share. Also, with Zoom’s 40 minute limit on the free version, you’re sure to stay within the time constraints of a good scrum meeting.

If you’re already using scrum meetings to power through your sprints, you’ll probably be familiar with the term ‘backlog’ – if you’re not, here’s a heads up.

A backlog might sound pretty negative, but it’s actually just a way of describing all the tasks needed to get your product built and out there. It will constantly evolve as you learn more about your product and its customers, so don’t panic if you’re never getting anywhere near the end. That’s not really the point.

What’s important for the scrum, is that your backlog is prioritised – and focused on user stories rather than technical tasks. If your developers understand why a certain feature matters to the user experience, they’ll be better able (and more motivated) to tackle it. And if you’re clear about priorities, you’ll be able to fight fires and move forward rather than sweat the small stuff.

So, as a team, keep your backlog organised, prioritised and understandable, so you can map your progress against it clearly in the scrum. And, on an individual level, encourage everyone to arrive with clear answers to their three questions in mind. No faffing.

We touched on this before, but it’s really at the heart of successful scrums – don’t try to solve everyone’s problems on the spot. That’s not what scrums are for. 

Yes, you’re asking people what’s standing in the way of them achieving their day’s goals, but resist the urge to dive in and fix things there and then. The whole team doesn’t need to be part of that discussion – it’s not relevant and it’s keeping them from their work.

In your scrum meetings, focus purely on identifying what those problems are – and recording them. Then, once everyone’s gone back to their desks, you can catch up with each person individually, giving them the time and attention they need to clear those blockages. 

If your team’s studio based, having a physical scrum board with stages mapped out and tickets you can move along is really helpful. It means that as each person talks, they can point to the work they’re tackling on the board, giving everyone an appreciation of where it fits into the bigger picture. You can replicate this for remote teams too, with a shared file you can each talk through.

A developer might get pulled away from core project work for all sorts of reasons – maybe a manager needed them on a special project, or an urgent bug needed their attention. It happens all the time. But if the whole purpose of your scrum is to push your dev team through a sprint, resist the temptation to let people talk about non-sprint-based work or problems. 

It might be that you give that kind of work a label, so you can all recognise the hard work they’ve been doing without shifting the focus of the scrum – maybe you could call urgent bug fixes ‘code reds’, and special requests from management ‘purple projects’. Whatever. Come up with your own language for it, but don’t dive into the specifics in your scrum.

On the other hand, if your scrum meetings are less about a specific sprint and more about working through what’s on the team’s plate each day, then by all means encourage everyone to (briefly!) share what they’re working on – including a quick visual so everyone can grasp the idea. You’ll be making everyone feel recognised, understood and motivated to keep cracking on.

Scrums aren’t the place for rambling. They’ve got to be short, sharp snapshots of your team’s tasks or they just won’t work. Make sure everyone knows this is the deal, and stick to it. People will soon start to value how fast they’re done, and how reliably they can plan their day afterwards. 

Don’t be tempted to let people sit down either – keep them standing up and you’ll all be out of there sooner. If it helps, you can give each person a time limit, so they’re clear on how long they’re expected to speak. You could even introduce an egg timer or a buzzer if that works for your team. 

We’ve also heard of people passing something heavy around their team to keep things moving along nicely. Try holding a can of soup out at arm’s length for the whole time you’re talking. You’re guaranteed to get to the point sharpish – and keep the tone of the meeting light and energetic.

Another great way to keep people on their toes is to vary the order people speak. If you just move around the group in the order everyone’s standing, you’ll find people stop listening to the person before them so they can mentally prep their own contribution. This is as much about listening as it is about speaking, so either pick people at random or get each speaker to nominate the next. 

They’ll appreciate all of those things – almost as much as they’ll appreciate being out of there in 15 minutes flat.

And if your team’s getting bogged down in bug fixes, try our new bug report template. It’s a quick, simple strategy that makes life easier for developers, account managers and clients – giving your team more time for the coding they love. Take a look.