6 Potent Power Patterns Every Scrum Master Can Use Today

Great Scrum Masters understand team development and intentionally coach and improve their team’s performance over time. A Scrum Master can equip Team Members with helpful tools and best practices by learning and using power patterns.

Power Patterns help the Scrum Master build happier teams that can work more efficiently, remain stable over time, and continue developing and expanding their skillsets. Power patterns should be incorporated throughout the Sprint and reaffirmed frequently.

If you are unfamiliar with power patterns, we’ve selected 10 essentials to illustrate the importance of coaching and development within a Scrum Team.

Happy teams are better performers over time

Most would agree that an engaged worker is more productive and generally better for the team and organization as a whole.

Less discussed is the subtle link between engagement and happiness that exists within individual team members. However, this is an important discussion because the happiest employees also tend to be the most loyal and engaged.

In Scrum, The Scrum Master should be intentional about measuring, analyzing, and improving happiness amongst the team even though it is difficult to attribute an increase in happiness to one specific change. Instead, the Scrum Team’s working agreement, communication, and activities are constantly iterating over time to increase this metric.

Quantum entanglement means forming a bond among team members

An interesting quirk of quantum physics is that it is possible to link together two particles to essentially make the two parts of the same whole. Once complete, these particles can be separated far apart, and still, one change will instantly reflect on the other.

In Scrum, we talk about quantum entanglement in the context of forming bonds with team members. Practically speaking, this means teams should work collocated as much as possible, especially in the beginning.

This power pattern has become more relevant than ever today as many teams find themselves working remotely, either temporarily or permanently. Without face-to-face meetings, it can be difficult for individual team members to form close bonds. In cases where some team members work remotely while others are collocated, negative ‘us and them’ behavior can develop.

To address this issue, consider following this three-step process when creating teams or adding team members to an existing team:

  • Initialize – establish a bond by encouraging team members to work together locally
  • Inspecting – The Scrum Master should intentionally watch for signs of team degradation and dysfunction
  • Adapting – If dysfunction is found, work should be done to repair the damage and reestablish face-to-face working experiences.

Stable teams provide more predictable results

Scrum Teams should be autonomous, empowered, and dynamically changing to meet the demands of the product they are creating.

At the team level, dynamic change can cause volatility in performance during the short term but will lead to stronger, more predictable performance increases over time. As a result, Scrum Teams thrive when they are kept small and stable because they can capitalize on the long-term benefits of doing good Scrum over time.

These stable teams tend to communicate better, work more efficiently, and continue to improve their performance over time incrementally.

At the organizational level, predictable results and reasonable expectations about the future allow leadership to make better decisions and achieve greater success.

Swarming helps complete PBIs more efficiently

The best Scrum Teams can prioritize working on one Product Backlog Item at a time as a team in a process known as ‘swarming.’

Swarming helps minimize the amount of work in progress by allowing the team to be creative as a group during production while also reinforcing the necessity of testing the product before moving on to another task. This behavior also helps teams avoid the compounding negative effect of task switching and multitasking.

As a best practice, allow one team member to take the lead on each PBI – everyone on the team must then help the leader complete the work until it is finished. Once complete, a new team member can take the lead on the next task.

Teams that finish early accelerate fast

The Scrum framework exists to help improve performance over time, and much of that work involves addressing the negative tendencies that many teams develop.

One such negative tendency among Scrum Teams is that they simply take too much work into their Sprint and cannot finish it. While occasional failure is expected and even healthy in some cases, frequent failure is demoralizing and leads to inconsistent or low performance over time.

Teams should focus on finishing a smaller amount of work early rather than a larger amount just in time to combat this issue. Extra time within the Sprint can sharpen skills amongst team members, pay down technical debt, and generally create opportunities for work multipliers to develop.

Fortunately, using Yesterday’s Weather and a powerful system for handling Interrupts helps keep the Scrum Team honest about their capabilities, allows them to celebrate successes, and contributes to faster acceleration over time.

Emergency procedures salvage work from a failed Sprint

Although the term ’emergency procedure’ sounds more appropriate for a fighter jet manual or a plant’s safety department, any team doing important work needs a system in place to protect them when things go wrong.

In Scrum, the Emergency Procedure Power Pattern exists to salvage a Sprint that is unable to be completed successfully due to the following reasons (or something else entirely):

  • A loss of personnel or equipment
  • Technical issues
  • Emergent and unavoidable interruptions
  • Overestimated work capacity
  • Underestimated work

Despite their best efforts, any one of these issues could cause a team to fail a Sprint. When the team realizes that the current Sprint cannot be completed, they should ‘push the red button’ and activate their emergency procedure.

Importantly, anyone on the team should feel capable of pushing this button and having a conversation as a team.

Typically, a Scrum Emergency Procedure will include:

  • Doing something different – changing the way the team does work or who is doing the work
  • Getting help – offloading backlog items to another team or accepting external help
  • Reducing the Sprint Goal to exclude a portion of the accepted work
  • Aborting the Sprint completely and replanning
  • Discussing the issue with management and stakeholders

Does Agile Scrum Kill Innovation? (Iterative Problem Solving)

Scrum is designed to solve interrelated problems common – but not unique – to software development projects: project scope and estimation.  

Do these problems also exist in innovation projects? Will the Scrum solutions work for innovation projects as well? Short answers: Yes and Yes. 

Applying Agile Scrum methodology to the process of Innovation allows the product team to define the scope of the project more clearly, identify emergent work more easily, estimate the work to be done more accurately, and demonstrate value to customers and stakeholders more frequently.

Let’s walk through what Scrum looks like within traditional software development and then pair it with common problems faced by innovative teams.

How Scrum uses emergent prioritized work to solve problems

Scrum developed ways to address the problem of project scope (the total amount of work needed before the project can be considered done). Since software can do so many things, it is hard to limit our needs. Therefore, project scope in software development has always been a huge problem.  

In software development projects, project scope usually starts out too big and only increases as the project progresses. Without understanding the project scope, it is hard to know when a software development project is ‘done.’ Therefore, projects often end when they run out of money or time, rather than being declared ‘done.’

Scrum addresses the project scope problem through ’emergent prioritized work,’ collectively referred to as the backlog. The backlog starts with currently known work and collects emergent work as the effort proceeds.

In Scrum, one person (the product owner) prioritizes the backlog; this makes the backlog manageable. In each iteration, the team faces a limited set of high-priority work and understands what it means to declare that set of work ‘done.’

When an iteration is completed, the project must always be functional so the users can touch and feel it for flaws or errors. Each time, the product owner shows the results to the users and asks their opinion on business value created or development errors (often some version of ‘what do you hate most’). In this way, the biggest possible mistake or waste of time is limited to a single iteration. If the project is off the rails, it can be reoriented before too much damage is caused. Thus, the process creates ideas for additional, emergent work which can be added to the backlog. 

The product owner prioritizes the backlog items according to business value. In this way, the product owner can compare the business value created by an iteration to the cost of that iteration. If there is no combination of work items with a total business value larger than the cost of an iteration, then the project is finished. 

Innovation projects have similar problems.

How do we decide what the most pressing problem is?

How can we know when we’re done (or even when we will be done)? 

Why Agile Scrum is best for innovation 

We build the result a little bit at a time, ensuring the work we’re doing fits within the whole idea of done and to make sure we’re also collecting any emergent work. This incremental approach helps solve scope problems in innovation projects, just like it does in software development projects.  

Another problem iteration can help solve is estimation. Everyone wants to know how much a solution will cost and/or when it will be done.  

Any time we discuss something in the future, we engage in estimation. Given what we understand in the present, we make predictions on how the future will play out. Unfortunately, the only truth we can predict is that humans are terrible predictors of the future (flying cars, anyone?).

In fact, we are so terrible at prediction that our only defense is to think small. Scrum helps solve this by using an iteration small enough that it allows:

  1. Product backlog items to be estimated reasonably well
  2. The risk of an estimation error to stay at a manageable size. 

Over a handful of iterations, the team’s productivity per iteration (velocity) becomes apparent. The product owner can then estimate the completion of the known backlog with a reasonable level of accuracy. If this estimate is over budget or schedule, the backlog can be pruned, and/or the organization can (carefully!) work to increase the team’s velocity. 

When you’re involved in innovation efforts, consider a lightweight Scrum process involving:

  1. A backlog of needs
  2. Iterations of work focused on a few specific needs from the backlog
  3. Regularly showing how your solution actually works (even if it works poorly).

This way, you can focus on the most valuable work while effectively collecting emergent work and managing costs and schedules.

Scrum Guide Changes in 2020 (What’s New?)

On November 18th, the 2020 updates to the Scrum Guide were released by Jeff Sutherland of Scrum Inc. and Ken Schwaber of Scrum.org that include changes to the way Scrum is defined and implemented, so we would like to provide a rundown of these changes and how it might impact your Scrum Team.

The 2020 Scrum Guide has been updated with simplified language to be less prescriptive and more focused on self-managed, unified teams. There is a new Sprint Planning topic, “Why,” and the three artifacts all received new commitments (Product Goal for the Product Backlog, Sprint Goal for the Sprint Backlog, and Definition of Done for the Increment).

Although the language and implementation have been streamlined and simplified, there are still many changes that active Scrum Teams will need to understand to update their own processes. Let’s go over the changes.

What changed in the 2020 Scrum Guide

While significant, it is important to understand that the changes to the Scrum Guide in 2020 do not deviate from the core principles of Scrum.

Rather, these changes are meant to standardize certain trends within the Scrum community, build upon Scrum’s rampant success within organizations, and make it more approachable for businesses that sit outside the IT-related fields that Scrum has historically dominated.

If we had to pick an overarching theme for the 2020 Scrum Guide update, it would be simplicity. More simplified language, more clarity around purpose, and fewer obstacles in the way of implementation.

Let’s check out the main changes to the Scrum Guide in 2020.

Less prescriptive than before

Scrum has always been a methodology rather than a structured system.

In fact, that’s part of the beauty of Scrum – it is an outline for a process that any business can use to both make better decisions about what they are working on and constantly improve how they are doing it.

Unfortunately, it has seemed in recent years that Scrum has gotten more prescriptive rather than less so.

With this update, however, Scrum is dialing back specific instruction in favor of providing a minimally sufficient framework that can be more easily adapted to fit the needs of new and different businesses.

Here are the most notable changes in this area:

  • Removed Daily Scrum questions
  • PBI attributes are handled more loosely
  • Retro items in the Sprint Backlog are handled more loosely
  • Fewer rules around Sprint cancellation

Resetting the team mindset – one team, one product

Scrum has always focused on empowered, self-organizing Scrum Teams to produce the best work possible.

Sometimes, however, the goals of the Product Owner and Developers can diverge and create a division within the Scrum Team. This ‘us vs. them’ mentality prevents the team from working on the right thing and causes them to do poorer work at the same time.

The 2020 Scrum Guide realigns the team’s effort around a new concept – the Product Goal – to help mitigate the divisiveness between the PO, SM, and Developers.

The new Product Goal

The best way to allow a team to focus on the same goal is to push it out far enough that everyone can see it.

With the introduction of the Product Goal, the entire Scrum Team can focus on a large, valuable objective in the distance and the primary mission of each Sprint becomes bringing the product one step closer to the Product Goal.

The benefit of this approach is that it shifts the focus away from the smaller details of a project and forces alignment around a larger vision.

The new Artifact commitments

Over the years, many terms and ideas central to the Scrum framework have been implemented despite the fact that they haven’t been formally defined.

Two examples of this are the Sprint Goal and the Definition of Done.

Although the Sprint Goal and Definition of Done are not new, the Scrum Guide has been updated to give them, along with the new Product Goal, a stronger identity within the Scrum framework by transforming them into commitments for the three artifacts.

Here is how they match up with the artifacts:

  • Product Backlog – Product Goal
  • Sprint Backlog – Sprint Goal
  • Increment – Definition of Done

By linking these ideas together more tightly, they provide more transparency and focus toward each artifact’s progress.

Self-managing vs. self-organizing

Scrum has always relied on the value that self-organized and empowered teams can provide to an organization.

In fact, it’s been demonstrated time and time again that teams perform better when they can choose who is doing the work and the best way to get it done.

With the 2020 update, the Scrum Guide takes self-organized teams a step further but allowing them to choose what to work on as well. This creates a team that not only organizes itself but also manages itself.

It also specifically changes the term ‘Development Team’ with simply ‘Developers’ to help eliminate this ‘team within a team’ phenomenon.

Another big note in the area of teams involves the Scrum Master.

While the 2017 Scrum Guide never mentioned accountability for the Scrum Master, the 2020 guide mentions it twice:

  • The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide
  • The Scrum Master is accountable for the Scrum Team’s effectiveness.

The message is clear here – the Scrum Master is in service to the organization as a whole and they must manage both up and down as ‘true leaders who serve’ rather than ‘servant leaders’ in their role.

In action, a self-managing team should be able to autocorrect itself and make constant improvements to what they work on, how they do it, and who is involved.

Introducing a new Sprint Planning topic

Sprint Planning has always included the “What” and “How” topics to determine the work that will be done within the Sprint.

In the 2020 update, emphasis is placed on a third topic, “Why,” which refers back to the Sprint Goal and reminds the team that they should always be asking themselves how the current Sprint will create progress on their overall Product Goal.

Along with the idea of self-managed teams, the new Sprint Planning topic reinforces the concept of doing the ‘right’ work.

Allowing Scrum to reach a wider audience

The 2017 Scrum Guide still contained many references to the IT-related fields that were crucial to the creation of Scrum, as well as a few redundant or complex statements that made the framework less approachable for some businesses.

With the 2020 update, the Scrum Guide has removed the redundant language and simplified the message of the Scrum framework so that it is easier to understand and implement within a wider audience. In fact, it’s about 30% shorter than the previous version and provides clearer and more actionable information for readers.

By changing up the tone and context of the Scrum framework, more and different businesses will be able to take advantage of a methodology that has proven to get twice the work done in half the time.

How is Sigao Studios handling these changes?

At Sigao, we’ve trained hundreds of students over the years on how to practice “good Scrum” and avoid “bad Scrum” using the principles and framework included within the Scrum Guide. We’ve also consulted with and worked alongside dozens of companies that depend on us to improve their business through Agile transformation and Scrum implementation.

With the 2020 Scrum Guide update, nothing changes – we will always provide the most up-to-date and relevant information for all of our clients and students.

Remember that Scrum is all about pivoting to adapt to the changing landscape, and these updates are just that – a pivot.

We look forward to bringing these changes into the real world so that we can test their effectiveness, continue to improve, and show everyone the value of Scrum.

Student Spotlight: Maureen Sears of HC3!

We recently caught up with Maureen Sears, Project Manager at HC3, to ask her about the impact that her recent Scrum Master and Product Owner training has made in her professional life.

HC3 is a data-driven tech company delivering customer communications for their clients. By managing complex data generated from multiple client systems, they help financial service organizations communicate with their customers in meaningful ways. HC3 offers focused solutions for statement and notice redesign, intelligent marketing campaigns, and seamless delivery of both print and digital communications. Through these solutions, HC3 empowers financial service organizations to give their customers a fully customizable document experience.

You can find out more about her company, HC3, right here.

Since this was a short interview format, I’ll just list the questions along with her responses below!

Q: How has the Scrum Master and Product Owner training changed the mindset with which you approach your business?

As a team, our Project Management team has adopted a more fluid perspective on how we handle implementations. Our improved mindset allows us to more easily adapt and grow with challenges that come our way.

Q: Have you incorporated any of the training into your workflow yet?

One of the most important pieces of training that we have incorporated into our workflow is the feedback loop.

Constantly sharing ideas between other departments and getting feedback from our clients has enabled us to deepen our understanding of other departments to create a better experience for our clients.

Q: Have you seen any immediate benefits to bringing these thought processes into your business?

Our digital solution HC3 offers our clients is constantly evolving and improving, so the implementation process is constantly evolving and improving at the same time.

We have been able to refine the process and tool more rapidly than ever before by including a constant internal and external feedback loop.

Q: Do you think LSM/LSPO training would be helpful for other startups?

This training did a great job of building the foundation for working in the Scrum world. It would be extremely beneficial for a startup because it is easier to get everyone’s commitment to building a new process instead of changing an existing one.

Q: Would it be an added benefit for all members of a team to have this training (so that everyone understands it and are on the same page)?

We were fortunate enough to have members of our project management team, as well as the manager of the development team, participate in the training. Having everyone together to think about how we could apply this knowledge in our work environment and bounce ideas off each other during the course was invaluable.

If you are interested in learning more about our LSM (Scrum Master) and LSPO (Product Owner) training classes then head over to our class page to get the details. Currently, those living near Birmingham, AL might even be eligible for a full scholarship to attend!

Agile Feedback from McLeod’s Perspective

Understanding your customers’ needs is critical for success, but getting there can be complex and time consuming.

We’ve gotten to know McLeod Software, one of the largest software development companies in Birmingham, AL, as a coaching client. McLeod is a leading creator of transportation and trucking management software for carriers, brokers, 3PL providers, and shippers.

McLeod User ConferenceMuch of McLeod’s success comes from listening to their customers and providing software solutions for their problems. On Oct. 3, they gathered more than 60 key customers for their Executive Advisory Council to gain greater understanding of their needs and generate input into their road-mapping process.

Sigao has worked with McLeod since January as they’ve transitioned their development methodology from waterfall to Agile. McLeod’s product managers didn’t want to leave any process untouched, so they brought Agile thinking into their EAC process and received a lot of positive feedback.

Here are some lessons learned from McLeod’s successful process.

It can be difficult to gather feedback from large crowds

McLeod used a crowd-voting platform to reduce a large group of possible features to a smaller, more focused group. This gave everyone an equal voice and ability to focus on mission-critical areas.

Long requirements-gathering sessions can be painful

McLeod provided opportunities to move around, injected humor throughout their meeting, and even provided “fidget items” like Slinky toys and pipe cleaners. Participants focus better through complex meetings when they’re allowed to move around and create.

Quiet people can easily hide in a crowd

When learning from your customers, you want to hear everyone. McLeod encouraged citizen note-takers to jot down any idea on a sticky note, then shared those ideas with the crowd. Everyone had a voice.

Developers can’t deliver everything in every release, so choices must be made

McLeod used a voting currency and MoSCoW prioritization to help developers find the functionality that will provide the highest value. This information will be combined with complexity estimates to build a product roadmap.

Moving forward with Agile

McLeod Gathering User FeedbackThese are just a few techniques McLeod used to create a successful platform for gauging customer feedback. As they continue to grow their Agile methodology, they will iterate on these ideas, increase the volume of their user voice, and reduce time-to-value for customers.

McLeod will host another mid-year Executive Advisory Council in 2019 and will no doubt have more innovation to offer their attendees.

If you want to learn how to develop better requirements from your users, reach out to us and let our coaches offer their insight.

Build a Better Developer Team by Increasing Employee Engagement Webinar

I’m excited to announce that I will be speaking in an upcoming webinar hosted by APN Consulting entitled “Build a Better Developer Team by Increasing Employee Engagement.” This employee engagement webinar is on July 7 at 1PM EDT and you can register by going to APN Consulting’s website. Registration is free and open to anyone interested in learning how to skyrocket your team’s performance.

Continue reading

How to Use AgileKit:Poker

Over the past month, the Sigao Studios team has been working on building AgileKit.IO, a suite of micro-tools designed to improve your agile team. Our first release is an agile estimation tool for playing agile estimation poker.

Create a game and invite friends

To begin playing poker, navigate to www.agilekit.io and press the green Create Game button.

AgileKit.IO Create Game Button
Once AgileKit has provisioned a new game room, you will be asked to give your name and an email address (If you have created a game in the past, you might not be asked again).
Poker Name and Email Dialog

The only thing we will use the email address for is to email you the results of the game at the end of the session.

Once you are in the game, you can send the room ID to your team so they can join you. They can do so by navigating directly to the link, or entering the 5-character code into the Join Game box on www.agilekit.io.

Poker Invitation Code

As your team members join, you will see them show up in the players list located in the top right of the game area.

Poker Players List

Create Some Product Backlog Items (PBIs)

In order to begin the game, you will need to add some PBIs to your game. If you have just created the game, you will have a blue dialog asking you to create a PBI. To do so, click the button. If you are in the game, you can add a new PBI by pressing the new PBI button located above the PBI list.


Poker New PBI Button

New PBIs show up in the PBI list located on the bottom right of the game screen.


You can edit or delete a PBI using the icons next to each PBI.

Play the Game

Once you have PBIs entered and your team has joined you can begin playing the game. The first step is to select a PBI you want to estimate by clicking the PBI in the items list. When you do that, that PBI will show up on your team members game board and you can begin the discussion.

AgileKit Poker PBI Card

When you are ready to vote, your team members can select the vote card that they wish to vote.


You will see their votes show up in your game board view.

Poker Votes Cast

When you are ready to see the votes, press the blue “Flip” button and everyone will see the votes.

Poker Votes Shown

Now, talk about the votes. Have the person with the lowest and highest explain why they voted the way they did. Promote open and frank conversation, and, if you reach consensus, enter the Score in the Score box on the PBI. If you would like to vote again, press the red Reset button and everyone will be able to cast another vote.

Poker Consensus Reached

When you are ready to view the next PBI, simply click on it in the Items window and it will show up for everyone and you can begin the voting process for that item.

Export the Game

Once you are ready to end the game, you can click the green Export button. You can do this as many times as you would like. You will be asked to complete a single question survey. Once you do that, press export and you will receive an email.

Poker Export Screen

Poker Email Results

Next steps

Sigao Studios is excited to offer this inaugural AgileKit tool. We have many more tools planned and are looking forward to creating a tool set that will help transform your agile and scrum organization. If you have any feedback or questions regarding this tool, please feel free to let us know. We are eager to hear how we can help your organization move forward in your agile methodology.