Keep Scrum Events Short

The Scrum framework includes five events. Each is an opportunity to inspect and adapt: to learn, to change direction and to improve. They provide just enough - but not too much - structure to enable the Scrum team to collaborate effectively. But too much of a good thing can create a whole lot of waste: long, drawn out events are almost never a good idea.

That's why each Scrum event has a maximum timebox. Those timeboxes are upper limits, not recommended durations! The goal is to make the events just long enough to achieve their purpose, and no longer.

1. The Sprint

The Sprint is timeboxed to a maximum of one month. Within that limit, it should be just long enough for the Developers to deliver a done Increment, and no longer. Two-week Sprints are the most common for software teams. Some teams, such as reporting teams, prefer one week. A few teams (for example, certain COBOL teams) have used three weeks. A team delivering physical hardware might need a full month.

A longer Sprint delays feedback and increases the investment in something that may not work. It also raises the chance that what is being built will miss stakeholder needs. In that sense, the Sprint acts as a timebox for risk: shorter is usually better.

The Product Owner’s needs matter too. Sprint length determines how often the Product Owner can engage stakeholders at the Sprint Review and adjust direction based on real feedback. Some products and stakeholder groups need that inspection more frequently than others.

Because the Sprint must result in something usable, the time required depends on the type of product. The Scrum team should decide what works best for their unique context. But when in doubt, select a shorter Sprint.

2. Sprint Planning

Sprint Planning is timeboxed at a maximum of eight hours for a one-month Sprint. I once sat through a full eight-hour Sprint Planning. It was terrible.

The problem was that we tried to do sizing and refinement right there in the meeting. It was simply too much. The next Sprint, we refined the Product Backlog in advance. From then on, Sprint Planning took no more than an hour for us. In that time, we created a Sprint Goal, selected the Product Backlog items we could deliver, and outlined our plan for delivering the Sprint. That's all we needed.

No one wants to meet just for the sake of meeting. Keep Sprint Planning focused on its purpose and end it when that purpose is met.

3. The Daily Scrum

The Daily Scrum is timeboxed at 15 minutes. Sadly, this is the event that most often goes for far too long.

When I was a new Scrum Master, I let the Daily Scrum regularly run to an hour. (I know, I cringe to think of it now.) I told myself I was being helpful by giving the team space to collaborate. Multiple team members later asked me to keep it inside the timebox. When I didn’t, some stopped coming. And then they all stopped coming.

The Daily Scrum exists so the Developers can plan their work for the next 24 hours and surface impediments. This isn't a team building or a problem-solving meeting or even a status meeting. It's a short, collaborative touch base.

So, identify the impediments, and talk about your plan for the next 24 hours. Then get back to work. Solve any issues outside the 15-minute timebox. Keep it short but effective, with just enough collaboration to improve the likelihood of delivering a done increment by the end of the Sprint.

4. The Sprint Review

The Sprint Review has a maximum timebox of four hours. I attended one that used the full four hours. It was boring and overwhelming. Stakeholders later told us it needed to be shorter.

After that experience, we kept the Sprint Review to about an hour. We focused on the key things delivered in the previous Sprint, demonstrated the Increment, and kept the collaboration with stakeholders brisk but meaningful. The event became far more useful.

The purpose is transparency, inspection, and adaptation. It's not supposed to be a comprehensive presentation, or worse: a report.

5. The Sprint Retrospective

The Sprint Retrospective is timeboxed at a maximum of three hours. In more than 20 years of using Scrum, I have never been in one that needed the full timebox.

Still, this is the Scrum Master’s most valuable event. The purpose of the Scrum Master is to improve the adoption of Scrum. The purpose of the Retrospective is to plan ways to increase quality and effectiveness. There is strong synergy here.

But that doesn't mean that the event should go on and on. And it doesn't need to be cute, and on the other hand it shouldn't be boringly repetitive either. It needs to be thoughtful enough to generate meaningful conversation, but it shouldn't go on and on either.

Here are a few ways to keep it revitalized and creative:

1. Ask someone beside the Scrum Master to facilitate it

   1. Why? It sends the message that this is the team's event and we should all care about continuous improvement

2. When it's appropriate, do an event focused on just one issue facing the Scrum team

   1. Why? Sometimes it's necessary to problem solve something specific. In those cases, you can use something like the Five Whys exercise to dig deep for a root cause.

3. And yes, sometimes the old standbys are useful

   1. Sometimes a simple technique like "What went well, what didn't go well, and ideas for improvement" is just what the doctor ordered. They're popular for a reason.

But always keep in mind that the goal of the retrospective is continuous improvement. A brisk meeting keeps it focused and on point. Not to mention that a brisk, timeboxed meeting also fosters creativity as well.

The Pattern

Scrum has just enough structure to enable team members to collaborate but not so much that it slows them down. Use only the time needed to achieve the purpose for each event, and then end get on with your day and let the team get on with theirs.

Why? Because shorter, focused events create better inspection, better adaptation, and higher engagement.

So, keep them short. Keep them purposeful. The team will thank you for it.