Tag Archive for: scrum

The History of Scrum

Today, Scrum has become one of the most widely adopted Agile frameworks. It enables teams and organizations to deliver value iteratively and incrementally, adapt to changing requirements and foster collaboration and self-organization. The influence of Scrum extends far beyond software development, shaping the way teams approach complex work across various industries. But how did everything begin and what were the main landmarks along the way? Here is a brief summary of the history of Scrum.

Read more

Scrum Courses 2022

Scrum Training in 2023

agile42 is a world leader is Scrum training. There are hundreds of training providers all across the globe, so what is it about agile42’s methods that keeps professionals coming back to us? We use scientific teaching methods and practices, including techniques from Accelerated Learning and in particular principles and concepts from Training from the Back of the Room.research has shown that students retain information better using these methods, and that conceptual understanding is deeper. In our training, we focus on the learners and not on the content, and we adapt our approach to each student’s specific needs and talents. The main points are covered, but we use different techniques and existing class knowledge to dive deeper into the concepts, which results in a dynamic agendathat aligns with the class’s specific interests.

Our Scrum courses are dynamic, designed for deeper practical understanding of new skills, and tailored for the individuals in the class. Sure, you’ll pass your exam. But you’ll also walk away with a greater depth of knowledge and understanding that will empower you when taking the next steps in your career.

Online Scrum Certifications

The agile42 training method has always been defined by interactive Scrum games, group work, and many, many post-its. But as our world changed and shifted due to the Covid-19 pandemic, we had to revise our training model. We didn’t want to fall into the trap of the formulaic video call, with a sequence of slides that flash across the screen while half the attendees are either dozing or distracted. We wanted to design training that kept the interactive, engaging agile42 style. This is how we devised our new training model: that of the “virtual class” with strong doses of interactivity and group activities thanks to the use of Zoom “breakout rooms”, beautiful Miro boards, virtual games, and a Slack channel that is available to the participants before, during, and after the course. Almost all of our Scrum training is available online.

Virtual Scrum Courses

Register for Scrum training now

Webinar: Why Technical Debt is an Opportunity

In software development, technical debt is a concept that reflects the extra development work that arises when we use quick or easy solutions. But the concept is useful beyond the world of software too. In the digital world, where new technologies and ideas are emerging just about every day, technical debt is almost unavoidable. So we need to know how to deal with it. 

Read and Watch

Common Agile Frameworks and Methods

During the last few decades, several approaches to product development and service delivery have emerged. The level of complexity of products and services is ever-increasing which is why many people wonder which framework or method to choose. Perhaps you are also wondering which framework or method will work best for your team. Below we summarize the key elements of four main agile frameworks and methods, some differences between them, and how they can complement one another.

Scrum

Scrum is a lightweight framework that helps teams and organizations deliver value incrementally.

The Scrum framework consists of the Scrum team with its three accountabilities, five Scrum events, and three artifacts. Each component serves a specific purpose and is important for Scrum’s successful adoption.

The easiest way to understand Scrum is to read the Scrum Guide. There are three main things that you should realize:

  • As an agile framework, Scrum has rigid boundaries. These are the specific team accountabilities, events and artifacts. Agile frameworks are intentionally incomplete and do not specify all the steps required to build and deliver a product or service. This provides the flexibility and freedom to apply the framework to various domains.
  • Scrum attaches particular importance to the cross-functional Scrum team and the accountabilities defined for the Developers, Scrum Master and Product Owner. Said accountabilities include maximizing customer value, improving team effectiveness and increasing product quality, among others.
  • Another key element of Scrum is the continuous improvement of the product, the team, its practices, and the working environment. This improvement typically happens but is not limited to regular sprint retrospectives. Retrospectives are arguably the most important event within the Scrum framework and should never be neglected.

Contrary to popular belief, Scrum is not an approach to estimate and plan what work will be completed in a given time period. Scrum allows teams to create value for their customers and users by letting them focus on one sprint goal at a time, while continuously getting better.

Recommended online course: Scrum Foundations

Extreme Programming (XP)

Nowadays, XP is not used as much as it was in the late 1990s and early 2000s. However, XP, its creator Kent Beck and other people like Ron Jeffries played a crucial role in the development of agile thinking and agile approaches. Therefore we would like to include XP in this list as well.

As the name suggests, Extreme Programming has its roots in software development. The core idea of XP is to develop software iteratively and incrementally while focussing on users’ needs. As such, it is an agile framework that is comparable to Scrum.

While there are many similarities between XP and Scrum, there are also subtle differences. For instance:

  • Iterations in XP tend to be shorter compared to sprints in Scrum.
  • Scrum teams typically avoid changes to their sprint plans while XP teams are more open to change.
  • The work of an XP team is prioritized by the customer while the work of a Scrum team is prioritized by their Product Owner.

The most important and noticeable difference, however, is that XP explicitly suggests development practices such as the following:

  • User stories
  • Spikes
  • Pair programming
  • Test-driven development
  • Refactoring
  • Continuous integration

These development practices are still being embraced by many software development teams, regardless which agile framework or method they adopt.

Recommended training: Certified Scrum Developer (CSD)

Kanban

The Kanban method helps organizations, teams and individuals manage their professional services, and enables them to respond better and faster to their customers’ needs and expectations.

The principles and practices of the Kanban method are described in the official Kanban Guide. Here are three important things to understand about Kanban:

  • Kanban is neither a methodology nor a framework. It does not prescribe events, workflows, roles or responsibilities. Rather, it is a method that is applied to an existing way of working, with the purpose of making that way of working more effective.
  • The myth around Kanban only being suitable for teams that are handling interrupt-driven, ad-hoc workload is unfounded. The Kanban method, with its change management and service delivery principles and its six core practices, can be applied to any process or system.
  • In many aspects, Kanban takes inspiration from lean manufacturing.

In his book “Kanban: Successful Evolutionary Change for Your Technology Business”, the creator of the Kanban method David J. Anderson, tells the story of his trip to Tokyo, in spring 2005. Spring is the cherry blossom season in Japan and he wanted to see the beautiful cherry trees at the Imperial Palace Gardens. There he realized they were using a kanban system to control how many people could visit the garden during peak times of the day. This kanban system, as used in lean manufacturing, inspired the Kanban method for knowledge work.

Related reading: How to create a Kanban board

In knowledge work, a kanban system allows work to flow by limiting work in progress and establishing a pull system. With the Kanban method, you visualize invisible work and how it moves through a workflow. This will help operate your business effectively, as well as understand and manage risks in delivering services to your customers. The Kanban method enables continuous improvement in an evolutionary way.

Because Kanban is almost universally applicable, many Scrum or XP teams use Kanban to improve their way of working, for instance by visualizing their work or optimizing their delivery. Some people call this a hybrid approach and give it a specific name such as “Scrumban”.

Recommended online course: Kanban Foundations

Design Thinking

Even though Design Thinking is not really considered an agile framework or method, its principles and practices are popular among agile teams and organizations and complement their toolbox. For instance, the persona is a widely used tool.

Design Thinking emerged much earlier than Scrum, XP or Kanban as it is based on the way designers approach new projects or products in general. Design Thinking has been developed by a number of different organizations (e.g. IDEO, HPI, Dark Horse) that follow slightly different approaches and theories. However, together they define what Design Thinking is.

Here are some important facts about Design Thinking:

  • Design Thinking fosters creativity by utilizing a large toolbox of practices, tools and techniques.
  • The core idea of Design Thinking is to understand the environment and the customer’s problem before building a solution. Design Thinking is based on continuous divergence and convergence.
  • Teams applying Design Thinking try to validate an idea for a solution by testing prototypes and iterating multiple times.

A major breakthrough was Jake Knapp’s book Sprint. Design sprints provide a structure that allows teams to prepare themselves for a challenge and solve it by going through all phases of Design Thinking within five days.

Recommended online course: Design Thinking Foundations

Which Agile Framework or Method Should You Use?

We often see teams asking themselves whether they should use one framework, method, approach or another in order to deliver outstanding value to their customers.

The reality is that you shouldn’t choose between Scrum, Kanban, XP, Design Thinking or others; rather, you should discover which practices work best for your team and tweak the system of work accordingly. By tweaking, we mean combining those elements that work best for your team in order to plan, track and manage your work more efficiently so that you satisfy your customers’ needs better and faster.

Ask yourself how work arrives at your team, and how often that work and the information around it changes. The answers could guide you in choosing a paradigm that suits you. You might find that a timeboxed mechanism or limiting your work in progress will help. Can you plan your work and commit to it for one or two weeks?

Scrum, Kanban, XP and Design Thinking aren’t mutually exclusive and complement each other when combined. The bigger challenge that lies ahead for teams is the journey of discovering which practices and structures work best for them in satisfying their customers’ needs in a sustainable and ever-growing way.

Every team, every product and every customer is different. There is no one-size-fits-all approach. By keeping an eye on what agility might offer beyond the methods, frameworks or tools you are already using, by trying out new things and hence continuously inspecting and adapting your system of work, you will eventually find what fulfills your team’s and customers’ needs best.

We hope this blog post made you curious about the idea of an agile mix-and-match approach and encourage you to find the best practices for your team right away:

  • Do you like the idea of having a Scrum Master? Try it out!
  • Pair programming sounds interesting? Go for it!
  • The concept of work in progress limits convinces you? Implement them!
  • Design sprints sound exciting? Just do it!

Want to Learn More About These Agile Frameworks and Methods?

agile42 offers online courses including Design Thinking Foundations, Scrum Foundations, and Kanban Foundations. We also offer Kanban System Design (KMP I) and Kanban Systems Improvement (KMP II) certifications, as well as coaching, mentoring, and consulting services. Reach out to us if you want to learn more.

Being a Dungeon Master Prepares You To Be a Scrum Master

When I was a kid, maybe eight years old, something magical happened to me. It was a sunny day. My parents had put a sliding door in our dining room, which lit up the space in gold every summer afternoon. That particular day, the room held my dad and a couple of his students from the high school where he taught Latin. They were limned in bright solar rays, excitedly talking about fighting goblins, looting gold, and casting spells while drinking Coca-Cola and rolling dice, having a grand old time.

Dad was the sponsor for his school’s wargaming club (later renamed to the ‘conflict simulation group’ at the behest of anxious administrators). Occasionally, his students would come to our house to play Dungeons and Dragons on the weekend. There was no satanic panic about the world’s most popular roleplaying game in our home. While my mother and my sister didn’t understand it (and still don’t), my father had caught the bug. He was happy to set up a space to play for the kids who could pay the toll to get across the Delaware River and drive the ten miles to our place.

I tottered in amongst the older kids, big as Hill Giants to me, and tugged at my dad’s sleeve. He looked down through his brown, plastic-framed Coke bottle glasses at me with a smile that was so rarely displayed to kids my age. I asked what was going on.

“We’re playing a game,” he told me.

I could tell he was anxious to get back to it, but I followed up with the obvious question: “Can I play?”

Dad laughed and told me no, I couldn’t. It was a bummer for sure, and he must have seen it in my face because he followed up quickly:

“Come back when you’re older.”

“How old?” I asked. I probably tried to hide my excitement and failed (something I still do poorly).

“I’d say twelve. Twelve?” He looked up at the other kids. I don’t think they were paying any attention, but I was. Because, even for a kid who struggled to pay attention to anything, this I would remember. Because this looked like so much fun.

Neither dad nor I knew that he’d be setting me up for not just the hobby that would define how I spent a large swathe of my recreational time moving forward, but also my experience with Scrum.

Ain’t No D&D Party Like an Agile D&D Party

I could tell you all about my time growing up in the hobby of tabletop roleplaying games (TTRPGs for short) – but this is not a gaming article. Instead, I’m writing about business. I’m supposed to write about goals. And, and, and… numbers. About making hard decisions and leading teams. We’re talking about planning for success and delivering products and value week after week.

And… figh… fighting goblins?

Well, as a life-long gamer, I can tell you that you will be amazed at how much Dungeons and Dragons can prepare you for business. Even more remarkably, how being the Emcee of a D&D game – a Dungeon Master – will prepare you for being a Scrum Master

Stay with me. I think you’re going to be very surprised.

The Basics of D&D

Before we get too far into the overlaps of Scrum Mastering and Dungeon Mastering, let me bring you in on what D&D (and any TTRPG in general) is, in case you’re in the dark.

D&D is a storytelling game where you and a group of friends take on the roles of adventurers in an elaborate fantasy world of swords and sorcery. These adventurers go on quests like defeating mad wizards or carrying out elaborate heists against tyrannical nobles. Players describe what those adventurers do in the world. A roll of the die determines anything that could be left up to chance (usually using a twenty-sided die or D20). One of the player’s jobs – the Dungeon Master (or DM) – is to set the stage and describe the world to the other players. The DM also takes on the roles of the supporting cast in the story, arbitrates (or throws out) rules where needed, and ensures everyone has a good time.

If it sounds like the DM has a challenging job, you are correct! I speak from experience here – I have been a DM for over thirty years across dozens of different campaigns and rules systems (D&D may be the World’s Most Popular Roleplaying Game, but it’s not the only one).

If it sounds like there are some similarities between the Scrum Master and the Dungeon Master, you are also correct. The similarities don’t stop at just the DM, though, so before we get too far into the similarities of DMs and Scrum Masters, let’s get down to some D&D brass tacks first. I promise not to get too nerdy on you.

Photo by S L on Unsplash

Scrum, Meet Party

Let’s talk about how a game of D&D looks through the prism of Agile (which I’ll refer to as Scrum World). Of course, D&D and Scrum World aren’t precisely one-to-one, so there are some things to map out for the sake of clarity:

  • The Scrum Team maps to what in D&D is called a “Party”. 
  • A Party typically comprises one DM and three to six Player Characters (PCs). The goal of the Party is usually to complete a story. The story can vary in length, but any given story will at least take several sessions, with an average session lasting two to four hours.
  • In this analogy, the DM is a Scrum Master (and, if I’m being honest, a Product Owner between sessions). The PCs are Developers.
  • The story is the product. The product’s Definition of Done is that everyone felt included, the story resolved to their satisfaction, and that everyone had a good time. To Quote master storyteller Neil Gaiman (@neilhimself): “It’s that simple, and it’s that hard.”
  • A session is equal to a Sprint.

Learn more about Scrum basics in our online short course, Scrum Foundations

Scrum Master, Meet Dungeon Master

So, how are the roles similar? Let us enumerate the ways.

The DM’s Job is to Continually Deliver Value Every Session

At Agile’s core is the principle of continuing to deliver a quality, functional product at the end of every sprint. The DM’s job is no different. If the DM fails, the PCs leave. The party gets together every week to play D&D because they want to tell a story that engages and excites them. If the DM can’t do that, those PCs can do other things with those two to four hours per week, especially when those players are Busy Adults With Many Things To Do. They can get together to play a board game or watch a movie without the pretense of also having to pretend to be a Druid if they’re not feeling it. So the DM has to deliver.

The DM’s product, the story, develops like any Scrum team’s product: action by action and scene by scene over several sessions, just like products are assembled over a series of Sprints. Software code is developed line by line; cars are engineered component by component; devices are tooled part by part. And as each Sprint rolls out, the output should get better and develop into something closer to that big beautiful idea everyone was dreaming of at the outset. As the collective project grows, it gets better, and the DM or Scrum Master makes those little subtle nudges that bring out the best of the project. This brings us to…

A Good DM Identifies the Strengths and Weaknesses of Their Players

The DM has to learn a lot about each PC around the table to put them in the right places at the appropriate times. For example, they know that bringing a Wizard to a knife fight is a bad idea (at least at a low level), in the same way that sending a Fighter to a diplomatic assembly of Archmages is a classic faux pas

Photo by Artem Maltsev on Unsplash

To be fair, a DM has an advantage that a Scrum Master doesn’t: narrative control. DMs can mold a story around the players that come to their table. But, more often than not, a Scrum Master already has the right people around them if an HR department has done their due diligence. But not all team members will be the same, and those little differences matter. Find out who your Rogues and Bards are (and let them be POs, those interpersonal skills are excellent for stakeholders). Identify Wizards and Sorcerers early (and give them caffeine judiciously). Use each person’s skills and talents and let them shine where they’ll do the most good.

A Surprising Amount of the DMs Job Is Tracking Metrics and KPIs

Ask any game fan about its nuts and bolts, and you’ll quickly discover that many numbers are spinning around. Look at pro baseball. All you have to do is flip over a baseball card – stats galore. You can argue about whether or not some of those stats indicate anything, but metrics count to stakeholders, and they hold you accountable to them. To the stakeholders of those pro sports teams, those stats are all Key Performance Indicators (KPIs), and if they dip too far, it’s back to the minors for those players or even farewell from the franchise entirely.

In D&D, it’s different, of course. PCs have a Character Sheet that lists all the things they can do in an even more concrete and non-debatable sense. Most relevant details are listed on that sheet, from how strong or fast they are to how well they take hits to how many spells they can learn and cast in a day.

Fail to keep your party’s KPIs up to snuff, and your PCs could find themselves tapped out of many encounters. Worse still, they could be overpowered more permanently at the end of some nasty critter’s claws. Well, on paper at least (if a character dies, they can always roll up another one or pay a cleric to resurrect them, c’est la vie). But, players are encouraged by an excellent DM to make sure that they keep their PCs moving toward their goals in a way that keeps the story enjoyable for everyone, and that means knowing how to set realistic goals based on capability. 

A good DM must know what a PC party can realistically handle in any given situation and set tasks accordingly. They best track that by the Party’s KPIs, which for a PC could be anything from their Armor Class, Damage Per Round, or the number of Spell Slots they have. Scrum World examples will vary, of course, based on the given Devs outputs. But, it maps in more similar ways than you’d think. Speaking of challenges…

A Wise DM Encourages Innovative Solutions (and Gets Failures Out of the Way Early)

A good DM also knows that they often have to put their players in positions where they might just fail. Failure is a part of the game, and it’s why dice are involved.

Any time there’s a chance something could go wrong, the DM calls for PCs to roll a die. The die result checks against a difficulty set by the DM. An easy D&D task is usually a 10, while something nearly impossible is a 30, with most tasks falling somewhere in the middle. And sometimes, even a high-level character rolls a one and botches at something in which they’re skilled.

It just happens. It’s going to happen to your developers in Scrum World, too. As both an experienced DM and a newly-minted Scrum Master, I’ve found that the earlier you can get that kind of thing out of the way, the better.

Case in point: a player in one of my parties had designed their PC as a healer. He chose to play a Cleric, a role traditionally suited to this (not always the case in fifth edition D&D, but that’s a whole other blog article for an entirely different place). When the first battle came around, he decided on the first round to surprise everyone. He waded into the fight and hit the bad guys with his staff. The Party took a beating with their healer tangled up in the melee. They survived though, albeit with more dings and scratches than they signed on for.

To their credit, no one in the Party got upset, but I held an impromptu Retrospective after the session. The big question was: why did the Cleric go in running? The answer was that he simply wanted to be helpful in the moment. The Cleric happened to roll high on his initiative, meaning he went first. No one was hurt yet, and he didn’t want to waste a turn, not thinking about holding his action instead of rushing in.

From that point forward, he knew waiting for the team to move in before committing to any actions was an option, making for a better strategy as a support member of the party. If things went well next time, sure: he could clobber some opponents. But, if he was going to shine as a healer, he might want to hold back no matter how good his initiative rolls were to see if a teammate needed support before going on the offensive.

Photo by lilartsy on Pexels.

A Smart DM Encourages Multiclassing

There is a school of thought among PCs in D&D Parties that staying in your lane is best. You should Know Your Role (in all capital letters) and never leave it. A Rogue should stick only to situations where they pick locks and can benefit from providing sneak attacks. A Warlock should always be in the back and cast Eldritch Blast on repeat into infinity. A Wizard should cast Magic Missile until they’re out of spell slots and then hide under a wagon until the fighting is over. 

It sounds reasonable. Players pick these roles because they want to be good at certain things. And those epic, level twenty powers sound cool. Who doesn’t want to max out a class and be the Thiefiest Thief to ever Thief?

I have a secret for you. Lean in close. I will lay some expert DM knowledge on you from my thirty-plus years of experience.

You’re never going to make it to level twenty. I have no intention of letting it go that far. Not in my campaign, at least.

Every D&D game I have ever run has either fallen apart or come to a close well before getting to that stupidly high-level threshold. The highest I’ve ever gotten as of this writing was a tenth-level Party. That campaign had single-class adventurers fighting tooth and nail with low saving throws against conditions that, if they multiclassed, would not have been problematic at all.

Anyone used to working with Scrum will tell you about cross-functionality. Building it into a team is at the crux of agility. A good DM learns this quickly and encourages this in their party. A Barbarian that can clobber a sentry or sneak around them after putting a couple of levels into the Rogue class will be able to hold onto their rages for better use later. A Fighter who can cast a couple of Mage cantrips can get an edge in their encounters without risking their neck quite as often. And the saving throws get nothing but better. 

Scrum World Developers similarly get better when a Scrum Master pushes them to develop accordingly, setting them up for success with the right coaching techniques and skills. In Scrum World, technology and science advance too quickly to let team members focus on a single discipline. Overspecialization can set Devs and their Scrum teams up for obsolescence or single points of failure. Coaching new skills and pushing teams to adopt new technologies and methods will keep your team cross-functional in a fast-changing world.

The Best DMs Know Planning is Good, But Being Prepared is Better

As a DM, I have had an entire story fall apart after a player with a lucky roll took out my villain in a single hit. There was supposed to be a whole arc with that villain as a recurring character. He would keep the party on their toes week after week as a nefarious player in the shadows. Instead, a single die roll ended the whole thing thirty minutes into the first session. Everyone went home, and I was intensely frustrated. I had a plan I worked on for hours, but I wasn’t prepared for a player to pick out the ridiculously overpowered weapon used to kill my bad guy.

There is a difference between having a plan and being prepared. With a plan, you have already committed to a specific course of action. You put things in place, worked out fine details, and estimated the functions of all the moving parts. There are processes and documentation you probably reviewed. You counted on those things to work out exactly as planned and with little deviation.

An experienced DM knows better. PCs – who are ideally the DMs friends and sometimes their family – are only there to have fun. They do not give a damn about any of the DM’s plans. They have their own ideas about how fun happens during the session and it may have nothing to do with a DM’s plan. All a DM can do is know the PCs and prepare based on what they know about the Party. DMs need to have a lot of options available to them, know where they all are, and to only dive into the specifics once they are needed.

PC (and Devs, for that matter) will not be little copies of the DM and will not act the exact way you want. Nor should they. PCs and Devs are human, unique. They bring something to your Party or Scrum team through different ways and means. It’s not something to be beaten out of them or micromanaged. Humans, shared stories, and volatile industries fiercely resist being wrangled in such a fashion

To approach complicated and uncertain situations with agility, a good DM or Scrum Master should prepare to optimally use their PC’s and Dev’s unique approaches and methodologies. Then, find the right coaching approach to engage them. When a Scrum Master or a DM can engage their Party or a Scrum team, it’s amazing what they can do.

As a DM, I must sometimes work hard to get in my players’ heads since I love bringing my favorite hobby to new players (new PCs haven’t learned how to be cynical PCs yet). Finding out how they approach the gaming table can be challenging. Do they like to fight, or do they like puzzles? Do they live for drama, or do they just want to help everyone around the table? Is the thrill of adventure something they live for? Or is it an excuse to cook for everyone around the table and see friends? Once I find what motivates them, I find the best way to run a game for that group… and then I can plan.

This Sounds Hard

It is hard—both the DM job and being a Scrum Master. Taking on either role takes serious determination and a lot of practice. But agile42 is here for you. The Scrum Master part, not the DM part! The good news is that everything here works in reverse, too. If you want to be a good DM, being a good Scrum Master is a great place to start! Book an appointment to speak with us at agile42 North America today to learn more about our coaching and training services. And, of course, go to DNDBeyond to learn more about Dungeons and Dragons, the World’s Most Popular Roleplaying Game.

Webinar on the Sprint Retrospective

Webinar | The Sprint Retrospective

In the final webinar of our webinar series on the Scrum Events, we discuss the Retrospective. The Scrum Guide defines the purpose of the Sprint Retrospective as “to plan ways to increase quality and effectiveness”. That sounds simple, but it’s actually one of the more complex Scrum Events. Watch as our coaches, Pascal Papathemelis and Ebru Yalcinkaya, take a closer look at Retros. They start by walking through the basics, like the basic structure of this event and what the Scrum Guide says about it. Then, while interacting with the audience and drawing on their experiences and challenges, they dive deeper, covering useful formats, common pitfalls, and some tips for making this event truly enlightening and productive for your teams.

Read and Watch

How to Facilitate a Sprint Review

The Sprint Review is an opportunity for the whole Scrum Team to stand in front of their users, stakeholders and customers and inspect and adapt the Product. It takes place at the end of the Sprint. The meeting should include an overview of the state of the product in terms of progress, budget and next steps. Usually, there is also a hands-on demonstration of the actual product. The users and stakeholders provide feedback, and then the developers incorporate relevant feedback into the Product Backlog.

What is a Sprint Review?

The Sprint Review is the third one of the Scrum Events that takes place within a Sprint. The purpose of a Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. It takes place on the last day of a Sprint, and is timeboxed to a maximum of four hours for a one-month Sprint.

Online Course Facilitating Scrum

What does the Scrum Guide say about the Sprint Review?

The Scrum Guide defines the purpose of the Sprint Review as a chance to “inspect the outcome of the Sprint and determine future adaptations”. 

The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.

During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.

 – The Scrum Guide, 2020

Who should attend the Sprint Review?

The Sprint Review should be attended by the whole Scrum Team (Product Owner, Developers, and Scrum Master) as well as the customers, stakeholders and users. 

What is the purpose of sprint review?

According to the Scrum Guide, “the purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations”. This is the key purpose of the event, and should be the focus. There are, however, a few other purposes and benefits to the event. Firstly, it enables you to improve your responsiveness to customers or users. Secondly, it helps with quality assurance, since your whole team and various other stakeholders will be present to inspect the product. Finally, it can help with team cohesion, as it’s a chance to get together and run through the various successes and challenges of the Sprint. 

Sprint Review vs Retrospective

Since both events involve inspecting the completed Sprint and adapting for the future, some people get the two events confused. However, there are some key differences: 

  • The Review is attended by the Scrum Team, stakeholders, and users, while the Retrospective is exclusively attended by the Scrum Team; 
  • The purpose of the Review is to improve the product, while the Retro is more focused on improving effectiveness;
  • The Sprint Review is timeboxed to a maximum of four hours for a one-month Sprint; while the Retro is expected to take less than three hours; 
  • The Sprint Review takes place on the last day of the Sprint, while the Retrospective takes place thereafter. 

How to improve your Sprint Reviewt

Photo by Jason Goodman on Unsplash

Tips to improve your Sprint Review

  • Consider it a chance to collaborate with stakeholders (not just a demo)
  • Get real users to give real feedback
  • Collect the feedback (but don’t act on it yet)
  • Create the right scenarios and focus on storytelling
  • Have a vision (the “big picture”)
  • Manage the backlogs
  • Don’t throw your PO under the bus: nothing should be a surprise for them
  • Let the team take charge

Sprint Review agenda

Below is a sample agenda or structure, which we use at agile42. 

Introduction

The SM, who acts as a facilitator, introduces the event by welcoming the participants. They explain the purpose of the meeting to the participants which can include users, stakeholders and customers. Then they show the agenda for the meeting. (5-10 min)

Inspection phase

The PO takes the lead and provides an overview of the state of the product in terms of progress, budget and next steps. They remind everyone of the Product Goal and describe the Sprint Goal the Developers were trying to achieve. (10 min)

The PO leaves the stage to the Developers to demonstrate the Increment. This is not a PowerPoint presentation of what the team has done, but a hands-on demonstration of the actual product. Usually Developers will go through the scenarios described in the acceptance criteria of each PBI. Some teams even let users or customers try the product themselves, while the Developers and the Product Owner observe how they interact with the Increment. (30 min)

The Scrum Team collects feedback on the Increment from all invited participants. (15-30 min)

Adaptation phase

Users, stakeholders and customers might leave the meeting at this point, while the Scrum Team continues with a working session to incorporate relevant feedback into the Product Backlog. Should the feedback be related to something which does not impact the upcoming Sprint, they can simply take notes to address the feedback in one of the upcoming Product Backlog Refinement sessions. However, if the feedback potentially affects the next Sprint Goal, the Scrum Team will perform a quick Product Backlog Refinement session during the Sprint Review to get ready for the upcoming Sprint Planning. (30 min)

Closing

The Scrum Master thanks the participants for their contribution and officially closes the event. (5 min)

Webinar: The Sprint Review

Webinar | The Sprint Review

In this webinar, we discuss the Sprint Review which is the most challenging Scrum Event according to our community. The symptoms are subtle and the causes deep: teams often fail to invite real customers, or they don’t know how to solicit and manage feedback. Our hosts, Dennis Büscher and Martin von Weissenberg, have facilitated, hosted and coached hundreds of Sprint Reviews, and in this webinar they share their insights, tips, and tricks with you. They begin with the basics and go over what the Scrum Guide says about the Sprint Review. Then they go a step further and share some of the most common pitfalls they’ve seen, as well as discuss best practices for getting the most out of this event. The webinar ends with a Q&A with our live audience.

Watch Now | Sprint Review Webinar

Stay in the loop about upcoming webinars by joining our mailing list

Meet your webinar hosts

Martin von Weissenberg is an experienced enterprise-level agile coach who believes that with the right leadership approach and change management tools, organisations can learn to change themselves in a structured and sustainable way. He has worked across the software industry for over 20 years, in startups as well as multinationals. Since joining agile42 in 2012, he has helped a large and diverse number of clients. These include organizations such as Siemens, ABB, Swedbank, Helsinki University, as well as countless shorter training and coaching engagements with companies in the banking, media, educational, telecom and marketing industries.

Martin is always interested in learning new things. So much so that he is currently completing his PhD on how to organize and lead for agility. This coupled with his empathetic and engaging nature, makes him well suited to drive transformations for both teams and larger organizations.

Dennis Büscher comes from a legal, agile project management, and human-centred design background. For more than three years, he has been coaching various companies and institutions in the fields of design thinking and legal design. Dennis worked at the HPI Academy as a project manager and coach for digital transformation and innovation training. Since 2021, Dennis has been a coach at agile42, supporting companies and organisations in the field of agility. He aims to drive innovation and empower teams through his user-centric approach and with the meaningful application of technology.

Browse the agile42 Agile Certifications

Facilitating Scrum online courses

agile42 offers Scrum courses, as well as:

3 Signs Your Daily Scrum Sucks (And How to Fix It)

There is an abundance of articles telling people how to do the Daily Scrum right, but a real scarcity of articles pointing out how to realize when things go wrong. Knowing the common pitfalls of the Daily Scrum and how to spot them can be a real game-changer in your teams. Here are three small, easy-to-observe signs that you need to fix your Daily Scrum.

Recommended online course: Facilitating Scrum

1. People are only interested in their own tasks

In many, many Daily Scrums you find that the team takes turns to each share their own tasks, progress, and impediments, rather than contributing to the discussion as a team. People normally follow with attention until it is their turn to speak, and they simply disconnect after that. This behavior is often amplified by the common way of running the Daily Scrum, i.e. the famous three questions. These questions are no longer in the Scrum Guide, because they can contribute to this problem. 

Further reading: Our comprehensive guide to the Scrum Events

How to fix it

There are two great ways to avoid this common pitfall and get the team to align towards the goal. 

One way that works is to keep the same three questions, but change things up a bit by having three rounds instead of one, with each person answering only one question at a time. 

This usually gives two benefits. The first is to keep people actively engaged until the end, since they know they will have to speak again. But there’s a more important benefit. It better serves the real purpose of the Daily Scrum: collectively assessing where the team is compared to the Sprint goal and collaboratively deciding what the next most important task is for each person to complete, in order to move closer to the Sprint goal. 

Daily Standup Meeting

Another way (which brings even more benefits in my experience) is to run the Daily Scrum by focusing on the stories in the Sprint Backlog, instead of focusing on people’s tasks. The idea is that the team selects one story at a time, going from the top, and discusses how to make it “done done” as soon as possible. Then you take the next story down and move on, either until you covered all the opened stories or until the 15-minutes time is up. In this way Developers will not focus just on the individual tasks, but will be nudged to look at the Sprint goal as a collective goal to achieve. 

When using this second method, sometimes you do not manage to talk about lower priority stories, so people who are working on those might feel a bit excluded. This isn’t always a bad thing: it can provide some social pressure to contribute to completing the highest priority stories first, instead of picking what they like most and spreading the team effort all over the Sprint Backlog.

Recommended online course: Facilitating Scrum 

2. Everybody is looking at the Scrum Master instead of at each other 

This is the biggest sign that your Daily Scrum has turned into a status report. Remember that this is not the point of this Scrum Event: the team should be updating and discussing the high-priority tasks with one another. 

How to fix it

Before the pandemic forced us to rethink the way we work and made remote work the standard, I used the trick to encourage the team to stay in a semicircle, closer to the task board, and I took (or asked the Scrum Master to take) a step back, pretending to take notes. If someone was stubborn enough to turn and try to speak to me, I removed eye contact, so that they felt a bit uncomfortable and were forced to find other eyes to look into: their teammate’s eyes. It worked immediately most times.

I used the same trick also when the team tended to look at the PO or their manager attending the Daily Scrum: I encouraged the team to stay in a semicircle, leaving all other attendees outside. If you want to replicate the same approach in a remote setting, just ask anyone else attending the Daily Scrum, except the Developers, to switch off their camera and mute themselves.

Daily Standup

3. People have long discussions, trying to fix problems during the standup 

I know that many Scrum Masters tend to interrupt discussions or ask people to continue conversations outside the meeting. This works to a certain extent, but usually, people find it a bit irritating.

How to fix it

I use and teach a different approach to this problem. First, I explain very clearly to the team that the Daily Scrum is intended for the Daily Planning, so that everybody understands and buys into this. Then, when I see that a discussion is taking off, I leave some space for 1-2 minutes. If it is not concluded yet, I ask the following question: How do you think this conversation can affect today’s planning? Most times people admit that it is not strictly relevant and propose to park it.

Do your Daily Scrums need more work? 

Of course, the three above and other dysfunctions might be just a symptom of something deeper. If the quick-fix techniques illustrated above do not work, it can be a hint of something more important that must be addressed. Consider taking an online course in facilitating Scrum to help you and your team have functional, useful Daily Scrums and other Scrum Events.

Webinar | The Daily Scrum

The Daily Scrum is found almost everywhere, even outside of Agile frameworks, but many organizations aren’t getting the most out of them. When run well, the Daily Scrum can be highly engaging, quick, proactive, and focused. Our coaches, Regina Martins and Lothar Fischmann, have facilitated, participated, and coached their way through thousands of these meetings, and share some of their insights with you. In this webinar, they start with the basics, cover what the Scrum Guide says about the Daily Scrum and share some tried and tested formats and methods that they have used. Finally, they answer your questions and share their greatest tips and tricks for getting the most out of this Event.

Watch Now | Daily Scrum Webinar

Stay in the loop about upcoming webinars by joining our mailing list 

Meet your webinar hosts

Regina Martins is an experienced business professional with a demonstrated history of working in the information technology, financial services and telecoms industries. As a facilitator and coach at agile42, she spends time getting teams from across the organisational hierarchies to communicate effectively. As a Radical Collaborator, she also helps people to collaborate better with each other and with other teams.

She also has been involved in the Africa Innovation Summit and the Agile Africa conference, as she is passionate about the Agile community in South Africa and continually strives to help keep it fresh. She also regularly speaks at conferences both locally and internationally.

Lothar Fischmann has a background in marketing and corporate communications. These experiences help him to turn agility into something more concrete and tangible. He is a team player who is passionate about creating supportive environments that foster creativity and learning. He also has a systematic approach that allows him to understand situations and develop scalable solutions that fit customers’ needs when helping teams and organisations go through agile transitions. Plus, Lothar always aims to add energy and humour when coaching or facilitating to keep teams engaged.

Browse the agile42Agile Certifications

Facilitating Scrum online courses

agile42 offers Scrum courses, as well as:

Tag Archive for: scrum

Certified Scrum Product Owner (CSPO) Training

Certified Scrum Product Owner (CSPO) Training

This course is an intense introduction to Agile Product Management, requirements definition and the Scrum framework.

The Product Owner Journey
  • Duration: 16h
  • Delivery: Remote / Face-to-face
  • Certifications: CSPO Certification (Scrum Alliance)
  • PDU: You can claim 14 PDUs for this training

Overview

Our Certified Scrum Product Owner (CSPO) training class is a learning experience that provides students a full immersion into what it takes to be a great Product Owner. You will learn the theory of the Scrum Framework and then we work through tools to enable great Product Ownership. 

The class is presented in a highly interactive and collaborative format with elements of lecture, classroom discussion, exercises, games and simulations, smoothly blended throughout the class. We will approach the class at a sustainable pace and endeavour to take breaks often, to allow our brain to stay focused and our body to recharge when necessary. 

Upon completion of the class, students will receive their Certified Scrum Product Owner (CSPO) certification and badges from the Scrum Alliance.

“The training reinforced for me the paradigm shift from the waterfall approach in a monolithic organization to Agile’s concept of servant leadership. Yes, I’m leading the team, but I’m here to enable your success.”

Michael M.

Pre-requisites

There is no pre-requisite for attending this class.

Target audience

The Certified Scrum Product Owner course is appropriate for aspiring Product Owners, business analysts, managers, project managers, and organizational team leaders seeking a deeper understanding of the Product Owner role, and how to improve Product Ownership in their organizations

Training topics

  • Scrum in a Nutshell
  • Understanding the role of the Product Owner
  • Techniques for building a compelling product vision 
  • Expressing the Product Goal using Opportunity Canvas
  • Models and techniques for prioritizing product features
  • Practical methods to understand your key customer segments
  • User Story Mapping: creating a shared understanding of customer needs
  • User Stories: eliciting and clearly defining stakeholder needs
  • Effective ways to create and refine a Product Backlog
  • How Product Ownership works with multiple teams

Included in the training

  • Product Owner Certification
  • Certificate + two-year membership to the Scrum Alliance
  • Slack channel to continue collaborating with your classmates after the class and access trainers to ask questions
  • Link to the Do Better Scrum booklet
  • Option to join the agile42 Community and get access to a number of free learning resources, like books, articles and videos
  • Life-long warranty on the course: e-mail access to the trainers

In case of a remote training

  • We will use Zoom as a video conferencing platform. 
  • We will use Slack as an additional messaging channel.
  • We will use Miro as an online whiteboard for digital collaboration.

Why agile42?

  • Experience: Over the years, agile42 has delivered Scrum & Agile training to thousands of professionals worldwide. Our instructors have decades of experience using and coaching Scrum in hundreds of organizations large and small.
  • Excellent ratings: We consistently receive excellent ratings from our participants. 
  • Techniques: In all of our classes, we use techniques from Accelerated Learning and in particular principles and concepts from Training from the Back of the Room
  • Engaging: Our courses are highly interactive and fun – not a PowerPoint assault, and our participants stay engaged throughout the class, learn by doing, and have fun along the way. When learners talk and teach, they learn. -Sharon Bowman
  • Practical and Memorable: Participants learn through hands-on exercises – creating high knowledge retention.
  • Sustainable: We are contributing to a greener planet by decreasing our carbon footprint by not having people travel to the venue, and less paper usage in terms of flipcharts and post-it notes.

Upcoming training

Scrum roles

Scrum Roles

Scrum is a lightweight Framework that helps teams to deliver value. Scrum describes three accountabilities, also known as Scrum roles, that make up the Scrum team: Product Owner, Scrum Master, and Scrum Developers, also sometimes simply known as the development team.

The Scrum Team’s primary focus is to make the best possible progress toward the Sprint goal, which is the single objective for the Sprint. Within a Scrum team, there are no sub-teams or hierarchies. Rather, the team is a self-organized and self-managing unit of professionals. In contrast to classical project management methods, Scrum doesn’t have a product manager or a team leader. Let’s dive into the different Scrum’s different roles and responsibilities.

Recommended e-learning: Learn about the different elements of the Scrum framework and why it works only in its entirety in our Scrum Foundations online course. 

The Product Owner

According to the Scrum Guide, the Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

Product Owner Responsibilities

 This role also holds a lot of accountability, as the name suggests. The PO has three key responsibilities.

Recommended for you: Product Owner Online Short Course

Manage the Product Backlog 

The Product Owner is usually one person who is accountable for effective Product Backlog management. The Product Backlog is an emergent, ordered list of what is needed to improve the product or service. This includes developing and communicating the product goal, creating and ordering product backlog items, and ensuring that the product backlog is transparent and visible at all times. As a result, they often have to prioritize work and backlog items by keeping the product goal in mind. 

Stakeholder Management 

Often the PO has to “fight on both sides”. The Scrum Team often works within a specific time frame (the Sprint). During the Sprint, the Product Owner often needs to deal with marketing, management, or customers in order to prioritize work and maximize value. The PO must be an excellent communicator, as they must be in contact with all stakeholders, sponsors, and the Scrum team throughout a project.

Return on Investment

The Product Owner is also responsible for the return on investment (ROI). They validate the solutions from the end-user’s point of view and verify whether the quality is acceptable or not. 

Product Owner vs Product Manager

Typically speaking, product managers are strategic and focus on the product’s vision as well as the company’s objectives and the market. Product Owners, on the other hand, are more tactical and focus on fulfilling a product vision by managing backlogs and working in cross-functional teams. A good Product Owner needs to be able to take responsibility, as the name suggests, for the success or failure of a project, which means they need to communicate effectively and juggle people’s expectations.

The Scrum Master

The Scrum Master (SM) is accountable for establishing Scrum as defined in the Scrum Guide. The SM helps to increase the team’s effectiveness by enabling continuous improvement and making sure that everyone understands the theory and practices of Scrum, both within teams and the whole organization. 

Recommended Training: Certified Scrum Master (CSM) Certification 

Scrum Master Responsibilities

According to the Scrum guide, “Scrum Masters are true leaders who serve the Scrum Team and the larger organization.” 

Improve the Team’s Effectiveness

The Scrum Master should create optimal working conditions for the team and keep these constant throughout the Sprint. This includes making sure that the team follows the Scrum Framework and understands all the elements of Scrum, including the five Scrum Events. They should have a comprehensive knowledge of Scrum and be able to act as a servant leader by creating the ideal environment for teams to thrive.

Remove Impediments

A Scrum Master is tasked with creating an environment for teams to thrive. They should aim to get rid of all possible impediments – or problems – that might disturb the work of the team. Usually problems can be classified in three different categories:

  • Problems the team cannot solve: For example, there may be a lack of necessary hardware or software, or a stakeholder such as a manager is making unrealistic demands of the team. 
  • Impediments related to organizational structure or strategic decisions: There are many examples of this. Perhaps the office or virtual workspace is not adequately set up to enable teamwork: maybe there is an unreliable internet connection, or meeting rooms aren’t available. Another common example is that the Scrum Master is viewed as being a project leader, and the team isn’t viewed as their equals. 
  • Problems related to the individuals:  This may include technical issues like computer crashes, or delays resulting from team members needing to wait for input to complete a task they’re unable to handle alone.  

The Scrum Master can’t and shouldn’t solve every problem alone, but they are still responsible for guiding the team towards solutions and removing impediments. This task often takes up a lot of time and requires great resilience and the ability to care deeply for the team. 

Serve the Whole Organization 

The SM should lead the organization in adopting Scrum. They should help employees and stakeholders enact and understand Scrum so that it can be successfully implemented. They may need to coach and advise in these instances.

 

Photo by Luca Calderone on Unsplash

Scrum Master vs Project Manager

The most obvious difference between a Project Manager and a Scrum Master is represented by the name itself. A Project Manager manages the project and sets the tasks, while the SM is in charge of ensuring that the team adheres to the Scrum framework. The Scrum Master does not interfere with the decisions of the team in terms of what they do, but acts as an advisor to the team when it comes to how they work. They only interfere when any participant in the project does not align with the principles of Scrum. A project manager, on the other hand, often gives directions and takes responsibility for the completion of tasks.

The Scrum Developers

The Developers, or sometimes simply referred to as the Scrum Team or development team, have all skills necessary to create a valuable Increment for each Sprint, and they self-manage. 

Scrum Developer Responsibilities

This team typically consists of three to five people and the specific skills needed by the Developers are often broad and will vary with the domain of work, however, they typically share the same set of responsibilities within a Sprint.

Create a Plan for the Sprint

The developers do not simply receive tasks from a project leader; they are self-managing and decide how many User Stories they can accomplish in one Sprint themselves. They create a plan for the Sprint, the Sprint Backlog (which is composed of the Sprint Goal, the Product Backlog items selected for the Sprint) as well as an actionable plan for delivering the Increment.

Manage and Execute Their Work 

The developers instill quality by adhering to a Definition of Done and work to ensure that they meet that standard. They may need to adapt their plan to reach the Sprint Goal and always hold one another accountable during the Sprint. 

Scrum Developers Work Differently from Traditional Teams

Developers in a Scrum Team decide on their tasks and are responsible for the execution of them – the team becomes a manager. The Scrum Master does not need to delegate all the work and plan the project

Get The Most out of Scrum

Scrum is simple to understand, but it can be difficult to master. Scrum is purposefully incomplete: It just defines the rules of the game, like the rules of a sport. That’s one reason why Scrum is hard to master: you need to know so many things outside Scrum to make it work successfully. 

And if you need help implementing Scrum in your organization, get in contact with us.