Scrum Teams: What’s with All the Scrum Meetings?
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 Scrum meetings are carefully designed to improve developer productivity and 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.
“The less meetings people have to be involved with, the better,” Dahlberg said. “Then developers can focus on doing the real work.”
There are five types of Scrum meetings held in regular intervals:
- Daily standup
- Sprint planning
- Sprint review
- Sprint retrospective
- Product backlog refinement
The daily standup is significant because it brings accountability to Scrum team members. These Scrum meetings occur throughout the sprint, and 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.
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.
At the end of the sprint, the Scrum team holds the sprint review to demo functionality and 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.
The sprint retrospective is a Scrum meeting used for just 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. The team also uses this Scrum meeting to 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.
Product Backlog Refinement
The product backlog refinement lasts one to two 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.
To learn more about the connection between Scrum teams and how they operate within an Agile framework, consider reading these other posts:
- The Difference Between Agile and Waterfall: Movement and Inertia
- How Scrum Teams Enable Mainframe Agility
Photo by Liv Martin and Chad Morgan
Latest posts by Michael Siemasz (see all)
- Three Signs Mainframe Customers Are Making Modernization Progress - March 6, 2018
- Five Traits of a Mainframe DevOps Olympian - February 8, 2018
- Eliminate Code Quality Headaches with Compuware and SonarSource - January 25, 2018