Key Points

• Scrum focuses on unified teams, rather than separate entities.
• Transparency within the use of artifacts takes special focus in the latest edition of the Scrum Guide.
• Teams are empowered to be more self-reliant when accomplishing Sprints.

The Scrum Guide is something of a living document, undergoing frequent revisions and changes to better suit the changes of today’s business needs. The most recent edition of the guide is the 2020 one, authored by Ken Schwaber and Jeff Sutherland. Now, for the average person, this is a fairly dense document, in part thanks to a hefty dose of nomenclature and jargon.

For active Scrum practitioners, this isn’t a problem, as they’ve likely been around to see the changes. For those new to the practice of Scrum, the Scrum Guide poses some immediate issues. So, today’s piece is centered around giving a high-level view of what’s in the guide and how it applies to your future project choices.

The One Scrum Team

One of the most notable additions to the latest Scrum guide is a heavier emphasis on singular teams within the framework. Previously, it was standard practice to have separate teams operating, like one using Scrum and an independent development team. Recent changes to the Scrum methodology have largely done away with this notion, instead focusing on making all teams within an organization stick to the approach.

This does away with the likes of microcultures that might develop in an organization. One of the bigger problems that can arise when tasked with separate goals and responsibilities is fostering an us vs. them mentality. The Scrum Guide seeks to do away with this notion entirely, along with another notable change.

Accountabilities

The idea of roles within Scrum is largely done away with, instead focusing on accountabilities. This collectivizes and ostensibly leads to greater cohesion within the team. You aren’t focusing solely on the responsibilities of your job title, but instead taking a broader focus toward what needs to be done throughout the project.

Unity is the name of the game when it comes to teamwork in the revised Scrum Guide, and it’s a welcome addition that will hopefully foster greater collaboration and teamwork on the whole.

Product Goals

Within other methodologies, the concept of a product goal isn’t uncommon. You’re working toward the future state of a completed deliverable. Scrum is embracing product goals as well, with long-term planning being supported as the Sprint Backlog changes and evolves throughout a project. This has some notable advantages, as the fluidity of Agile and Scrum alike makes for quick adaptations. However, it is prone to scope creep, so having a long-term, concrete end-state for a product allows teams to stay on target.

Sprints are conducted for the sole purpose of clearing the backlog, and this further impacts the product goal over the long term. When you’re committing to decisions, completing features, and getting tasks off the Backlog, you’re striving closer and closer to the final, ideal state of your product.

Artifacts

The term artifacts likely conjures up an entirely different mental image than what applies to Agile. However, throughout any given project, there are data points and pieces of information that arise as a simple matter of completing sprints. Artifacts within Scrum take a heavy focus, appearing in your daily Scrum meetings, the Product Backlog, and throughout the entire process. These are the details and features of a finished project, dictated by what is realistically achievable in conjunction with customer desires.

Transparency and Focus

The three main artifacts of the Scrum process, Product Backlog, Sprint Backlog, and Increment, have changed somewhat compared to previous versions of the Scrum Guide. Now, they have a commitment associated with them, meaning they’re tied to other aspects of the project as you move through them. Your Product Backlog directly commits to the Product Goal, with the other artifacts corresponding to aspects like the Sprint Goal and the Definition of Done, respectively. This promotes transparency and enhances the overall focus of a project, a must for today’s market.

Self-Managing

Empowerment of team members has been central to Scrum and Agile for years now. However, the latest edition of the Scrum Guide takes a heavier focus on autonomy. Teams are largely self-managing in the latest version, deciding who works on what and when to do so in the first place. The heavier emphasis towards empowerment is a boon for most organizations, as a self-managing team can be highly motivated by accomplishing tasks delegated to them.

Sprint Planning

Sprint planning is a vital task for any Scrum project. Without it, Sprints simply aren’t viable, as you need the terms of what is being done and when laid out plainly for everyone in the team to see. Sprint planning initiates the process of a Sprint, focusing on remaining items in the Backlog to see what comes next before moving to the next task. Sprints are done fairly quickly, with most lasting a few weeks at the most.

Asking Why

One major addition to Sprint Planning comes in the form of three major questions. There are as follows:

Why is this Sprint valuable?

Product Owners often start the process of Sprint Planning. This first question is on the value added to the product, and emphasizing why the current Sprint is important to stakeholders. The team then needs to work together to establish a Sprint Goal, something which needs to be pinned down before the end of planning.

What can be done this Sprint?

At this stage, the team will start looking at what is realistically accomplished from the Product Backlog during this Sprint. Items can be refined and polished as needed, increasing overall confidence and comprehension of what needs to be done.

This essentially relies on the current capacity of any Scrum team, as the work accomplished needs to fit within what is viable. From there, the Sprint forecast is starting to take shape.

How will the chosen work get done?

Each item on the Product Backlog gets marked off as they are accomplished, but this final question chooses to address how this is accomplished. The Definition of Done for every team is vastly different, relating entirely to their capacity and how they approach Increments. However, this final question reinforces why the work is being done and its overall importance to the project at hand.

Broader Applicability

Scrum and Agile have spent decades as the preferred approach for software development. As times change and technology makes its presence felt across just about every business sector, times have changed. We’re seeing the wider adoption of Scrum principles in businesses that couldn’t be more removed from software development. As such, the Scrum Guide is focusing on broad strokes rather than specific disciplines applicable to development.

Not Just Software

This broad strokes approach has heavily shaped the way Scrum and the language surrounding it. Rather than operating on the codified three questions asked at every Scrum, it’s a looser approach, allowing teams to forge their approach to the daily meetings to better suit the needs of the team and organization. This wider applicability reflects the changing times and is likely to see Scrum adopted throughout a wide variety of industries over the coming years.

Elevated Scrum Masters

The final talking point today focuses on Scrum Masters. Previously, Scrum Masters were beholden to the goals and objectives of a given project, without concrete leadership or authority over a team. However, this has changed somewhat, with Scrum Masters acting as a guiding figure over the entire Scrum project. This change emphasizes adhering to and sticking to the principles and philosophy behind Scrum, allowing an organization to plan and shift as necessary.

Other Useful Tools and Concepts

Now that we’ve spent some time demystifying the latest Scrum Guide, there are likely some other topics that might interest you from our catalog. For instance, learning how to ably transition from Waterfall to Scrum can be an endeavor fraught with missteps and failure. With a few practical strategies, you can make the most of the transition.

Further, you might be interested in the most common mistakes made in Hoshin Kanri. There are few approaches as well suited to strategic planning as Hoshin Kanri, but not every implementation is going to be foolproof. Taking a practical, systematic approach to planning can yield greater success.

Conclusion

The Scrum Guide is a vital document for any organization practicing the methodology. The changes made are fairly substantial, but they give a broader applicability and more clarity on how to approach projects and the various components within. Hopefully, you’ve come away from today’s guide with a richer understanding of Scrum.

The image featured at the top of this post is ©Ground Picture/Shutterstock.com.