All Hands on Deck: Scrums and Sprints

This is the fourth of a series of introductory posts about Scrum. The previous post discussed User Stories, and the Product Backlog.

Hello! Wow, it’s great to see you again.

So you may have noticed that we’ve spent an awful lot of time talking what “Scrum” is, but we haven’t yet talked about what “a Scrum” is. We also briefly introduced the topic of Sprint Planning meetings in the last post, and this post will expand on the topic. Yes, today, we’re talking about that thing we do when we’re not working.

That’s right, folks: I’m talking about meetings.

As you’ve probably already surmised, Scrum principally makes use of two kinds of meetings: the Scrum, and the Sprint Planning meeting. Let’s start with the first.

A Scrum is brief stand-up meeting, typically held daily. Importantly, the Product Owner (PO) is not invited. Doing this is important, because (intentionally or not) the presence of the PO can bias the behaviour of the Development Team Members (DTMs) in the meeting. The structure of a Scrum is simple, but effective; In a Scrum, the Scrum Master (SM) asks the following three questions of each DTM:

  • What have you been working on?
  • What are you working on now?
  • What are the roadblocks?


Apologies to Terry Gilliam.

That’s it! These three questions are all that are needed to get everyone on the same page. In this way, team members can share their successes and raise issues before they become serious impediments to the team. It’s important to note that these meetings are not for updating the SM as much as they are for helping the DTMs to update each other: as is sometimes/often/always the case, unexpected issues arise in the course of a Sprint, and it’s frequently helpful to keep the lines of communication open so that DTMs can get access to each others’ expertise.

A Sprint Planning meeting, however, is a much more intense affair. For a typical sprint of three weeks, six hours of Sprint Planning is realistic! This seems like a nightmare of a marathon of a meeting, but if an ounce of prevention is worth a pound of cure, then it’s better to spend the time in Sprint Planning early to avoid lost time later on. This meeting, again, is run by the SM – and this time, the entire team is invited.

These meetings are the ones where the SM has the opportunity to do the most good for the team, and they’re the meetings where the SM’s capacity for team-building, mediation, and leadership can shine through. The User Story (US) at the top of the Product Backlog (PB) is the first to be discussed, and it is discussed exhaustively. The SM must mediate this conversation by asking how the US is to be accomplished, what needs to be done in order to conclude the US, and – perhaps most importantly – which DTMs will carry them out. The list of USs in the Sprint are stored in a list called (you guessed it!) the Sprint Backlog (SB).


I would at this time like to reiterate that nobody tells the DTMs what to do. It is critical that DTMs volunteer for their USs of choice, and that they are never to be commanded, ordered, instructed, delegated, persuaded, coerced, cajoled, coaxed, or hoodwinked into taking USs.

I don’t want to make this sound like a trivial process, because it isn’t. In general, attempting to fathom the scope of each US discussed in the Sprint Planning meeting is a feat – and on top of that, people are notoriously bad at self-assessment! There exist tools for estimating the amount of time and effort required for each US – for example, systems of assigning difficulty points to USs – but the most important tools in the SM’s kit will always be their aptitude for asking the right questions, encouraging constructive participation, detecting and amplifying the underrepresented voice in the room, and building consensus about how the team tackles the backlog.

When these meetings work well, they’re a beautiful thing to behold.


This diagram is true for all effective mediation.

I’ve left a couple of things off the list of items to be discussed in Sprint Planning, and that’s because they’re important enough to merit their own post. All I’ll say for now is that if you’re the kind of person who demands evidence before concluding that you have good results, then you’re going to want to read what’s coming up next. Stay tuned.

These articles are for you! Please don’t hesitate to ask questions or give comments. Let me know what you’d like to see, and what’s unclear – and, in true Scrum fashion, I’ll try to tune the future posts so they’re more interesting, informative, and entertaining for you.