Meetings! Huh! What are they good for?
Absolutely … some things!
(with my apologies to Norman Whitfield, Barrett Strong, and Edwin Starr)
People regularly lament about meetings. I am guilty of it myself. I used to cynically and sarcastically say, after spending time in a long and fruitless meeting, “Meeting rhymes with beating!” Many would often shake their head in agreement. “There are too many meetings” is a common refrain at many companies. Interestingly, I often hear this after groups have adopted Scrum, “Why are there so many meetings in Scrum?” “Isn’t Scrum supposed to be lightweight? Agile?” Let’s quickly review what meetings Scrum defines and then we will see what happens in practice for many teams, especially when starting out with Scrum.
The 5 Scrum meetings
- Sprint Planning
- Daily Scrum
- Backlog Refinement
- Sprint Review
- Sprint Retrospective
These are the four original meetings plus “Backlog Refinement”, which has recently become part of Scrum (see http://agileatlas.org/atlas/scrum).
Sprint Planning
Purpose: Development Team commits to work they plan to get to the Definition of Done by the end of the Sprint (the Team’s Sprint Goal).
Outcome: A solid Team commitment to a Sprint Goal represented by their Sprint Backlog (containing all the Product Backlog Items (PBIs) and, possibly, task breakdown).
Duration: 2 hours per week of sprint, often less, as teams mature and improve.
When: At the start of a Sprint (after the Sprint Review and the Sprint Retrospective).
Who: Development Team, Product Owner should be available to clarify PBIs, Scrum Master facilitates.
Daily Scrum
Purpose: Daily meeting for the Development Team to inspect and adapt how to best achieve their Sprint Goal.
Outcome: Impediments get surfaced and improvements for the day’s work are agreed upon.
Duration: 15 minutes per day.
When: Every day of the Sprint.
Who: Development Team, others can attend but only listen, Scrum Master facilitates.
Backlog Refinement
Purpose: Product Owner helps the Development Team to understand the work coming in the next Sprint or two. Sometimes this involves writing acceptance criteria, slicing items smaller, sizing, estimating, or anything that helps the team prepare for the next Sprint Planning.
Outcome: Upcoming PBIs are ready for the upcoming Sprint Planning Meeting.
Duration: Varies by team but is often 1-2 hours per week of the Sprint.
When: Varies, but preferably not immediately followed by Sprint Planning. Try to allow a day or two in between these meetings.
Who: Development Team and Product Owner, anyone else who can increase the Team’s understanding, Scrum Master facilitates.
Sprint Review
Purpose: The Development Team demonstrates the PBIs they believe have achieved the Definition of Done to the Product Owner and other stakeholders.
Outcome: Feedback for the Development Team on what they built, often resulting in the generation of new PBIs. Also, a broadly understood view of current progress.
Duration: One hour per week of Sprint, but can vary depending on the number of teams demoing and how big the audience is.
When: At the end of the Sprint, before the Sprint Retrospective and the Sprint Planning Meeting.
Who: Development Team, Product Owner, generally, anyone else can attend, especially desired are stakeholders, Scrum Master facilitates.
Sprint Retrospective
Purpose: The Development Team gets together to examine how they have worked together during the previous Sprint and what they will try in the next Sprint to improve.
Outcome: One specific experiment the Development Team will put at the top of their next Sprint Backlog.
Duration: One hour per week of Sprint.
When: At the end of the Sprint, after the Sprint Review and before the Sprint Planning Meeting.
Who: Development Team, Scrum Master facilitates.
There are a large number of variations on the above descriptions but I think of these as a good starting point. If I customize the process, I don’t lose sight of the purpose or the “why” of each meeting.
Special thanks to ICAgile and Ahmed Sidky for the inspiration for these two graphs.
If you add up all the meeting time vs. time for building the product or service (or doing agile vs being agile), you get:That’s larger than a 6:1 ratio. Looks very lightweight to me. Where does the complaint about too many meetings come from then?
Cause: Poorly refined Product Backlog
A Product Backlog that is not well-refined will not be well-understood by the Team. They will need time to gain enough understanding to make a solid commitment to the Sprint Goal. This refinement ends up taking up most, if not all, of the planning time. Time usually runs out and a rushed Sprint Goal is created. So much work gets packed into the Sprint, during the Sprint there is no time to refine the Backlog for the next Sprint, perpetuating the problem. Sprint Goals in this circumstance are rarely reached.
Cause: Poor meeting facilitation and/or weak team agreements
This meeting is truly for the Team to synchronize and coordinate their efforts for the day so that the Team can be as effective as possible. But, other items leak in like reporting status to a leader, deep-diving on problem solving, staff meeting agendas, etc.
Cure:
Instead of trying to describe what needs to happen, let Jeff Sutherland, the co-founder of Scrum, describe the Daily Scrum in a two-minute video:
Notice he mentions the type of agreements Teams can have, e.g. “We can talk about one issue for no more than 60 seconds…” When Teams hold each other accountable to their own agreements can lead to much more effective and dynamic Daily Scrums and eliminate much waste.
Cause: Not focusing on the Agile principle of “working software as the primary measure of progress”
Many traditional project management views about reporting progress are rooted in the idea that you can estimate the percentage of completion of work. Unfortunately, reporting that something is 50% finished lacks information needed to use for decision making. It makes it difficult to answer the “Are we ready to ship?” question. Also, people want to be recognized for the effort spent on the work to date so they hesitate leaving anything out.
Cure: Only demo “potentially release product increments”
By only demoing the PBIs that meet the Definition of Done, it is very clear to everyone in attendance what real progress has been made. A decision to ship is now much easier to make. This gives the organization real business agility. Teams improve from rarely completing anything in their Sprint Goal to completing nearly everything after making this change.
Cure: Choose one actionable improvement per Sprint
By only choosing one experiment to try in the next Sprint and making it specific and actionable, we increase the odds of actually making improvements. It gives Teams something to reflect on during the next Retrospective. Over time, repeatedly making small improvements will add up to many significant improvements for the Team willing to learn and experiment.
