Scrum is a popular way of working in teams. Many people however, dislike one core element of Scrum: the meetings.
Scrum meetings are often time consuming, boring and ineffective. Meetings run overtime, discussions keep going in circles and decisions are rarely made. If a decision is made, it's usually that "we should have a meeting about that". This is ineffective and frustrating. It’s no wonder people flinch when they hear "Scrum". But it doesn't have to be that way.
As the scrum master, you have the power to make the team meetings more effective. Here are some tips on how to do that.
Your goal as a (part-time) scrum master should be to make the team more effective.
Usually the team expects you to host events such as the daily, retrospective and review. You can meet this expectation by doing the following things:
- Plan all the meetings
- Show up at each meeting
- Introduce the agenda
- Keep a check on the time
Doing just that often meets the team's expectations. But does that really make the team more effective?
It's Not About You
You can approach your role in two different ways:
The first is by becoming a chairperson. You can do this by giving people turns in speaking, summarizing everything people have said and regularly introducing your own topics and insights. Your substantial involvement in meetings shows that you are a valuable part of the team.
As chairperson you have created a bunch of dialogues between team members and yourself. Where is the team in that?
The second is by becoming a guide. You can do this by letting on-topic discussions flow, get people involved and keeping your opinions (often) to yourself. As a guide, you leave the pathfinding up to the team. That doesn't mean you've lost sight of the (meeting's) goal though. Your involvement will be far less visible than as a chairperson, but its impact will be felt when absent.
Guiding the team means your team will have to collaborate and take ownership of discussions and their decisions.
Here's how you can put this into practice:
Facilitating Scrum Events
The retrospective is your most important meeting.
The team can reflect, highlight and complain. Your task is to have the team gather insights and turn them into action. If you fail to do this, the retrospective will become an hour (or more!) of complaining. Insights without actions will lead to frustration.
This means the main focus is action. To get to action, you can follow these steps:
- Gather insights: The easiest way is to have a format and let people provide their thoughts on stickies. It helps to limit the number of stickies they can use For example, only allow 2 stickies per person. Otherwise you will have to reduce discussion items in the next step, making it more time consuming.
- Group Insights: By grouping insights, the team will read each other's insight and start seeing patterns. This can speed up the next step.
- Prioritize and limit insights: Often the team has a lot to discuss. It's essential to limit the scope of the discussion, so that you can get to creating action items. You can limit the items through voting and picking the top two or three item groups.
- Discuss insights: To clarify insights, discussion is often required. Opinions differ and the team should agree on the appropriate action. It's important that this is done respecting people's opinion and in a timely fashion. The discussion is often where most time is spent, often resulting in a lack of action.
- Defines action items: Have the team describe what it is that they are going to do. Make sure the action is described precisely, is limited in scope and is in your team's circle of influence.
- Assign and plan action items: Determine who can take on this action and when to do it. Aim to perform the action as soon as possible, ideally in the next sprint. If you don't, the discussion may return in the next retrospective. This will lead to frustration.
Finding The Right Retrospective Format
Using an appropriate format leads to better insights, which will lead to better actions. Using the same format over and over again, will get boring quickly. Make sure to adjust the format according to the team's needs. Determining the team's needs takes time and practice, so here are some ideas:
Once you get a good feel for these, you can start expanding your repertoire. Combine new formats with your personal insights about the team. Do you feel the team is trying to reach a big and challenging goal? Try Sailboat, or Mountain Climbing. Feel like the team is a negative mood? Try doing Something Positive. Looking to make the team help people grow? Try Personal Growth. Need to break the ice before people enjoy retro's? Start with an Energizer.
Retrospective templates are widely available online. Try to remix existing templates or even create your own.
Here, the team presents their work to their peers and stakeholders. They'll gather feedback and assess progress.
You can make the review more effective by:
- Making an agenda by gathering topics that team members will present.
- Inviting stakeholders and confirm they will join.
- Sharing the agenda with stakeholders upfront.
- Discuss sprint progress at the start of the meeting*
- Discuss plans for the next sprint*
* This could or even should be the role of the Product Owner, but they don't always do it. It's your choice to do it, or have them do it
Refinement & Planning
Refinement and planning work in tandem to provide the contents of the next sprint(s).
- Refine work items: Make sure that the work that you are doing is clearly defined. This increases transparency, enables handover of work and allows the team to estimate the effort. Ideally, items have been outlined before the meeting, so that the team has enough information to refine items.
- Estimate effort: How much effort will this work take? Use story points to estimate difficulty, complexity and uncertainty. Estimation is not about being correct, it's about being close enough. When estimations differ wildly, it can lead to valuable discussions. The team can choose to refine the item again, split it up or converge on an estimate.
- Order Items: According to the Scrum Guide, the Product Owner is responsible for "Ordering Product Backlog items". In practice, it's often done in collaboration with the team. The team and Product Owner can give each other more insights, which can lead to better ordering.
If you refine well, planning will become easier and faster:
- Limit topics in the sprint: Having a large amount of different topics in the sprint reduces collaboration and increases the chance of work not getting finished. This can lead to frustration and reduced speed.
- Plan for capacity: The total effort of all items in the sprint should be less than the team's capacity. The easiest way of calculating the team's capacity is by looking at how much story points have been finished in the last sprint. Not planning for capacity will lead to the team not finishing their work. This leads to frustration and a lack of trust in the team's ability to deliver. By tracking capacity, scoping the next sprint will become easier.
Things that you often hear during these meetings are:
- "I cannot estimate this story, because it will be different for person A than it is for person B". That's not a problem. Estimates don't have to be correct, they just have to be somewhat close. By averaging or taking the most common estimate, you'll get close enough.
- "I cannot estimate this story, because it's a research topic and I have no idea when it'll be done". This happens a lot in research heavy fields such as Data Science. To make sure work gets finished, there is a possible solution: Timeboxing. Limit the amount of time that can be spent on research. If you get a result within the time limit, that's great. If you don't, stop the work and write a follow-up story.
Too often, daily standup meetings look like this: Each team member will give a status update: What have they done, what will they do and too often what meetings they've had. Others will barely listen, until they hear their name being mentioned. They'll quick sit upright and give a similar mundane sounding update as all the others. Repeat until all team members have said their update.
This is far from fun!
A standup should be used to:
- Resolve blockers: Is someone being blocked? Or is one of your products broken? This is the time for you or the team to bring it up. Discuss the blocker and do something about it. Is your whole standup spent on how you are going to get your failing database back online? Great!
- Initiate collaboration: The standup is the right place to tell people you'd like some help, get a review on your code or would like to pair-program. Make sure the collaboration starts outside of the standup, though.
- Share highlights: Encourage the team to focus on their accomplishments, lessons learned and even failures. This allows the team to celebrate even small successes, which can foster a positive team culture. It also establishes a habit of framing failures or helping others as valuable contributions.
- Assess progress: Have a look at how the team's been progressing. Using the sprint board as a guide can help here, but is not always required.
You can achieve a fun standup by maintaining focus on the above items, letting the team have the discussion and keeping everything timely.
Running effective scrum meetings create a fun and engaging meeting culture. This leads to better collaboration and productivity, which positively impacts your team's success and satisfaction.