If you’ve been a scrum master for some time, you have learned some of the practices that make teams successful:
- You know how to help teams commit and deliver results at the end of sprints.
- You handle blocks so that they aren’t impediments to the team completing more difficult user stories.
- You know how to run the fundamental meetings including commitment, standups, demos, and retrospectives.
You also have developed some strategies to work with product owners:
- You help them groom their backlogs and prioritize the user stories that drive business value.
- You provide feedback on user stories to ensure they follow best practices on format and provide a clear definition on who the customer is, what value the story provides them, why it’s important, and what constraints must be met in the implementation.
- You update product owners the sprint status and articulate any risks or blocks the team escalates.
But what are the next set of scrum master skills that you should master? This article details what you should learn and do to become an elite scrum master.
Related video: The scrum master role explained
How scrum masters drive business and IT alignment
The scrum master’s role as a go-between to coordinate between the product owner and the development team can fuels the divide between business and IT by forcing funneled messages back and forth. Elite scrum masters break through this division by providing a different level of collaboration.
Start with the overall planning process and how user stories go from an important idea that has customer value to a flushed-out set of user stories scheduled in sprints. The key question is how much dialog occurs between the product owner and the team in the formulation of these user stories. Having little dialog indicates a division between business and IT that should be repaired.
If there is little dialog, the scrum master should think of creating opportunities for groups to plan together. One practice is to create recurring brainstorming sessions so at least part of the team can participate in defining the vision behind a feature. A second practice is to give the team the option to contribute ideas and acceptance criteria to user stories. This practice enables the team to document non-functional or technical requirements as acceptance criteria in the story or to include technical debt as part of the feature scope.
How to better estimate user stories and drive minimum viable products
Once development teams are following a basic scrum practice, it’s time to consider whether and how they can provide estimates on user stories. There is still some debate over how to do this, and some people even argue that scrum teams should provide no estimates. But many scrum experts advocate estimates when used for the right reasons.
I recommend that development teams do make estimates for user stories, under the guidance of the scrum master. Here’s why: One agile principle is to ship software early and to target minimum viable products (MVPs). The rationale is that once the product ships, you can begin getting feedback from customers on how to make improvements. Targeting MVPs also helps organizations prevent over engineering (and over investing) in too many features up front. But how do organizations shape MVPs when human nature is to ask for everything, and it’s often hard for product owners to prioritize feedback from many customer voices?
Having the neutral development team provide estimates can help product owners make priority and scope decisions. If a marginal value feature has a high estimate, the product owner is likely to lower its priority. If a feature has several user stories that have high estimates, the product owner may reevaluate the scope of the feature and consider other less expensive approaches to achieve the same or similar results.
I have posted guidance on why and how to estimate, and there are many agile estimation techniques to consider. You should investigate to see which one best fits your organization. Many organizations elect to use a composite measure called story points to measure an aggregate of both the effort, complexity, and other factors in implementing the user story.
How to maintain a consistent velocity and forecast with burndowns
It takes some time for your estimation process to mature. Development teams have to get used to providing consistent estimates, and product owners have to learn to use this data for sound decision-making.
It can take three or more sprints to get sufficient uniformity in the estimates. At that point, the scrum master can then begin using the aggregate of these measures to help the product owner and the team.
Teams are usually interested in their velocity, the sum of the story point estimates in the sprint and benchmarked over the last several sprints, to help them make quantified decisions on how much to commit in future sprints. Measuring and discussing the velocity is also good to discuss in retrospectives to see if there is opportunity to improve productivity to increase velocity, or if the team is overcommitting—either way, this helps you adjust to get more accurate estimates.
In addition to measuring velocity, many agile tools produce burndown charts based on the aggregate of their estimates. Burndown charts can help the scrum master and teams understand whether a sprint is on track or whether they are falling behind. When user stories are tied to epics, the aggregate of estimates provide a percent-complete measure and the burndown can help forecast how many sprints are needed to complete all user stories aligned with it.
How scrum masters should work with engineering teams
Estimates are also a vehicle to help bring in engineering, operations, and infrastructure teams into the scrum process. They can also be a vehicle to help establish devops practices.
To get there, many development teams start with basic release management that helps everyone understand what will be delivered when. Of course, this isn’t simple because providing a fixed scope, fixed timeline, and (probably) fixed budget and quality are elements of the iron triangle that project managers understand—and what makes forecasting difficult.
But when there is a sufficiently large backlog with estimates, scrum masters can tag prioritized user stories to releases and use release burndowns to help make the trade-offs between when and how much to package in a release.
Release schedules are great tool to bring engineering teams into the agile process because release schedules help them understand the timing and target scope of the changes scheduled to be deployed to the operating environment. The procedures often imposed by the operations team can delay delivery of the development team’s work, adding time beyond the sprints for the ultimate product delivery and slow down a process that is supposed to be agile. That’s a common frustration for scrum masters.
But scrum masters can use release management practices to close the gap, preferably leading to a defined devops practice where development and operational teams invest in continuous integration, continuous delivery, and infrastructure as code.
How scrum masters should handle conflicting priorities
To enable scrum to go beyond development teams and into a business process, it must extend to both the business teams and operational teams. For business teams, you as the scrum master should help enable agile planning to fill the backlog. For the engineering teams, you should enable release management practices to ensure releases can be performed frequently and reliably.
Of course, it never is that simple, and tactical conflicts come up frequently. Do you take on a user story after the sprint starts because the product owner has a critical request? Do you address technical debt in the scope of a business deliverable or do you help the team record it to be prioritized at a later time? Do you pressure the team to go above its typical velocity to hit the targeted scope of a release? Do you pull team members off development priorities when engineers escalate a production issue?
These and many other similar conflicts come up in every organization. In addition to juggling various tactical concerns, there are also cultural issues to handle, and perhaps to improve: Are teams fighting when conflicts surface, or are team members empathetic and find ways to address issues together? When teams work their way through a conflict, the scrum master should find a way to establish a path to resolve similar issues when they come up in the future. If a conflict does get ugly, the scrum master should help people look beyond the conflict and find a way back to friendly collaboration.
What sets the elite scrum masters apart is that they effectively manage both types of conflicts.
How to size the scrum master role to your organization’s size
Large organizations, as well as ones that move people across teams frequently, are more likely to have dedicated scrum masters to help establish working agile practices with teams.
But small organizations—especially those that have matured their agile teams and practices—are less likely to require dedicated scrum masters. They may need scrum masters or agile coaches initially to institute the agile development process, but once accomplished they shift scrum master responsibilities across multiple people (technical leads, business analysts, and other departmental roles)—as a set of responsibilities instead of as a position.
Either way, building your scrum master skills leads to a several career opportunities. If you enjoy the role, consider becoming a certified enterprise coach (CEC) or get training in professional agile leadership essentials.
If you work in a small organization where the scrum master position is temporary, you could use your scrum master experience to find a job in a large organization that has dedicated scrum masters—or you could learn aspects of the product ownership role or of devops practices to pave the way for a different job in the same organization.
For any scrum master, learning scrum practices, driving an agile culture and mindset, and executing the role as broadly as possible provide great rewards and career opportunities.
Isaac Sacolick is the author of Driving Digital: The Leader’s Guide to Business Transformation through Technology, which covers many practices such as agile, devops, and data science that are critical to successful digital transformation programs. Sacolick is a recognized top social CIO, a long-time blogger at Social, Agile and Transformation and CIO.com, and president of StarCIO.