One of the main contentions people have with Agile is it involves too many meetings, in particular the Scrum meetings a Scrum team holds during two-week sprints.
But it’s a misguided notion that Agile is overstocked with superfluous meetings, according to Josh Dahlberg, Scrum Master for Compuware’s iStrobe and Fault Analytics. He says that Scrum meetings are carefully designed to:
- Improve developer productivity
- Prevent impromptu meetings from impeding development and operations work
But what else makes Scrum meetings so different than your typical corporate get-together?
Parameters are set around these meetings to cut down on the waste of excessive discussions that cause a need for additional meetings. For instance, Scrum meetings are time-boxed and discussions veering from the core content of a meeting aren’t allowed. This disciplined atmosphere allows Scrum teams to spend more time developing and solving problems rather than sitting in meetings all day.
As Dahlberg says:
“The less meetings people have to be involved with, the better. Then developers can focus on doing the real work.”
Types of Scrum meetings
There are five types of Scrum meetings held in regular intervals:
Let’s take a look at each.
Daily standup
The daily standup is significant because it brings accountability to Scrum team members. These Scrum meetings occur throughout the sprint. Every day, members answer three main questions:
- What did you do yesterday?
- What are you doing today?
- Is anything impeding your progress?
“What you worked on yesterday, what you’re working on today—it’s expected that it’s stuff in the current sprint, stuff we’ve previously committed to delivering,” Dahlberg said.
Having Scrum teams provide information on these questions helps the Scrum master see if anything could potentially hinder progress. But it’s also an opportunity to determine more effective paths to completion.
“Everyone gives a status update and says if there’s anything prohibiting them from accomplishing their commitments,” Dahlberg said. “If someone says they’re still working on a particular piece of functionality and that’s an impediment to someone else, we can address it.”
Another benefit of the daily standup is transparency. Anyone in the organization is welcome to sit-in and listen to everything discussed in the daily standup, although only the Scrum team can speak—time is limited.
“Someone might have an interest in seeing where the Scrum team is in the sprint so they can make considerations for the future,” Dahlberg said. If the Scrum team is working on something that could impact another area, it would make sense the for person(s) working in that area to be aware.
Sprint planning
If a sprint is the working process of Agile, sprint planning is the beginning of that process.
“Sprint planning lines up the work and gives estimates so you know from the beginning what your capacity is based how many people are on your team, who’s got vacation, how many hours you have to work with, and what you can accomplish in two weeks with the capacity you have available,” Dahlberg said.
This Scrum meeting should last two hours for every week of the sprint—so a two-week sprint would call for a four-hour max Scrum meeting.
(Avoid spring planning panic with these expert tips.)
Sprint review
At the end of the sprint, the Scrum team holds the sprint review to:
- Demo functionality
- Discuss with shareholders and others what was accomplished during the sprint
“Feedback may vary story to story,” Dahlberg said, “but generally we’re hoping for a conversation to make new functionality better.”
During the feedback process, a product owner might provide feedback on changing a feature after seeing and disapproving of the original concept. Team members might inquire about what API was used to accomplish a piece of work and potentially offer more efficient alternatives.
This Scrum meeting should last one hour for each week of the sprint. For instance, a two-week sprint would include a two-hour sprint review.
(Consider combining teams for agile sprint reviews.)
Sprint retrospective
The sprint retrospective is a Scrum meeting only for the Scrum team, to meet and reflect upon the last sprint.
“It has a lot of value because it’s about our processes and internal improvement,” Dahlberg said.
During the sprint retrospective, the Scrum team:
- Revisits things that did or didn’t work during the last sprint
- Determine what things to change or continue
The sprint retrospective should last around one hour. If you’re moving through a sprint retrospective in less than 45 minutes, you likely aren’t getting optimal value out of the Scrum meeting, according to Dahlberg.
(Maximize sprint retrospective value with these 10 tips.)
Product backlog refinement
The product backlog refinement lasts 1-2 hours, depending on the Scrum team, and occurs between sprints. It gives Scrum teams a chance to:
- Evaluate a story for clarity, size, and feasibility
- Learn what’s coming up in the next sprint
- Express concerns early in the process
- Make sprint planning move quicker
“A product owner has an idea of what they expect a piece of functionality to look like at the end of each sprint,” Dahlberg said. “The refinement meeting exists for having a technical discussion about a user story, and ensuring the Scrum team understands the requirements and that what’s being asked is deliverable within a sprint.”
Scrum meetings aid Mainframe agility
Mainframe agility is now a competitive requirement for enterprises in the accelerating digital economy.
Agile provides the development framework for IT organizations to thrive in a fast-paced environment, and Scrum meetings are an indispensable component of that framework that help Scrum teams carry out more efficient development and delivery of functionality.
Related reading
- BMC Mainframe Blog
- BMC DevOps Blog
- What is Sprint Zero? Sprint Zero Explained
- Scrum vs Kanban: A Comparison of Agile Methodologies
- The Scaled Agile Framework (SAFe): What To Know & How To Start
- Top Agile Certifications To Earn
- Agile ITSM: How Agile & Service Management Can Work Together
See an error or have a suggestion? Please let us know by emailing blogs@bmc.com.
