Rethinking scrum as a project-based stand-up

Tuesday through Friday at 10 a.m., the Storytelling Studio starts the morning on a video call for scrum. Scrum, also referred to as a stand-up, is a five-minute check-in about the day’s work, with the primary goal of identifying blockers. Monday’s meeting is slightly longer and reserved for weekly planning. Up until a few weeks ago, each Studio team member shared an update that hit on three points, in 30 seconds or less:

• What she or he worked on yesterday
• What she or he is working on today
• Blockers and steps to remove blockers

As the Studio shifted to work on larger projects with multiple team members, our updates became less descriptive. We started to default to a rundown of meetings instead of specific tasks or priorities. Listing meetings is easier than context-switching between different tasks and projects that need focus in a given day, especially in a 30-second update. But just listing meetings isn’t useful for anyone — especially for me, as the project manager who usually schedules them.

In addition, while up until recently the team had overlapped on projects, most now only touch a few. Individual scrum updates about multiple projects were hard to follow and didn’t provide a cohesive overview of where a project was on a given day. We ended up trying to connect the dots between many people’s updates, which were given out of order and independent of others working on the same task.

So, after one particularly update-less scrum, we decided to remix it.

Focus on projects

Rather than focus on the individual, our new scrum format highlights projects and the mini-teams working on each. The Studio typically works on 4-5 larger storytelling projects at a time, in addition to smaller tasks like writing blog posts. I keep a running list of these projects, and associated team members, to walk through in stand-up. Once everyone working on one project has given an update, we move onto the next.

Because not all work falls neatly into project buckets, I also end each scrum with two catch-all questions: Anything I missed? Any blockers that weren’t raised?

Prioritize tasks

Updates should be task-based, not a run-down of meetings. Most team members are juggling more than one project at a time, so its easier to speak to tasks project-by-project. Everyone is more accountable for what they are doing that day, for each project.

Focusing on tasks also helps identify if a team member needs more information about a deliverable or isn’t clear what he or she should prioritize on a given day, which is helpful for me to track what to follow up on after scrum.

Facilitate transparency

As a project manager, I have a granular view of everything the team is working on. While the rest of the team shouldn’t be expected to know that level of detail, it’s important there’s transparency into all projects to avoid silos and encourage knowledge sharing. We’ve noticed the subtle switch in scrum format better facilitates transparency, and gives everyone a high-level understanding of what's happening on projects they aren’t directly involved in.

Identify blockers early

Meeting daily enables the team to raise blockers early and often, with work to remove blockers handled outside of the meeting. While our approach to identifying blockers in scrum hasn’t changed, we’ve found it is easier to talk about blockers collectively at the project-level and determine next steps in the room.