5 Whole-Team Workshops To Increase Developers’ Role In Sprint Planning

7 minute read

Run these activities with the whole team to increase not only the developers’ role in sprint plannings, but also collaboration, engagement, and value creation!

Drawing of a hand representing 5 activities, and a developer with a growing voice under the caption @ Sprint Planning. Here are 5 activities to increase developers' role in sprint plannings.

Tools have taken over the meaning. I need to chant “The card is a token for an ongoing conversation” over and over. (George Paci extremeprogramming@groups.io)

The devs had no say in what stories went into the sprint (David Kramer extremeprogramming@groups.io)

[ndlr: In Parallel to] The rise of the ‘Product Manager’ job, which is a strange combo of a member of the sales organization and a surrogate user. Engineers no longer can talk to users. (Slava Imeshev extremeprogramming@groups.io)

Nowadays, it looks like developers are often stuck in their development roles. They are rarely involved in product management decisions. In this context, they receive user stories like “tasks to do.”

From a rational point of view, we can explain this situation with two typical human biases:

  • We tend to underestimate the importance of soft topics. Here, we overlook the impacts of collaboration, trust, understanding, and implication.
  • We tend to keep things for ourselves because we want to stay in control.

Yet, as coaches, we see teams and developers suffering from this situation. Sure, we understand where this is coming from… We are humans, not 100% rational robots, though! As a result, it’s easy to fall into disillusion or rebellion!

Wouldn’t it be great if you knew ways to make all stakeholders – product experts, developers, and quality people – collaborate to plan what goes into the sprint?

Here are 5 whole-team workshops to build team spirit and trust between stakeholders. Eventually, they should make everyone collaborate towards the same direction:

  1. Practice an Example Mapping kata
  2. Agree on a scope with a Big-Picture Event Storming
  3. Play the built-in quality game
  4. Agree and improve a whole-team test strategy
  5. Address technical debt from a business perspective

Each of these activities should increase the developers’ role in sprint planning. And guess what, greater collaboration on planning is not only good for developers! As a second-order effect, it will:

  • Improve product management decisions
  • Increase developer motivation
  • Reduce developer stress
  • And finally, increase the value creation.

It’s a clear win-win for everyone!

1. Practice an Example Mapping kata

Illustrative Example-Mapping cards in their typical layout. Example-Mapping is a format for quick and cheap, domain-heavy conversation. It's a lightweight and informal way to bootstrap more collaboration with product experts, and eventually increase the developers' role in sprint planning.
Sample Example-Mapping cards on the introductory post about Example-Mapping, by Matt Wynne

I already wrote about how to inject Example-Mapping into your process. It is also possible to run a kata to learn Example-Mapping. Any kata with enough ‘domain’ will do. For example, the Mars Rover Kata is a great fit. Here is how to do:

  • Invite the product and quality experts.
  • Hand the kata specs to the product person, but don’t say a word to others.
  • Make them run the example mapping to discover the specs.

If you don’t know the Example Mapping workshop yet, you can learn more about it in these posts.

2. Agree on a Scope with Big-Picture Event Storming

Drawing of an Event Storming workshop where we can see the participants discussing in front of the 'infinite design board'. Big Picture Event Storming is a great workshop to kickstart intense collaboration between all participants right from the start of a new project. As a result, it also increases the developer's role in sprint plannings.

A new target is a perfect occasion to run a Big-Picture Event Storming. Propose one next time the team starts a new product, a new important feature, or some rearchitecting. There are at least three collaboration benefits:

  1. Participants will collaborate closely during the workshop. As a consequence, all stakeholders will know and trust each other more. Trust is the foundation for more collaboration on planning.
  2. Often, developers accumulate a huge domain-knowledge debt. Big-Picture Event Storming is an accelerated way to pay it back. With more domain knowledge, developers’ role in the sprint planning will increase.
  3. Participants will map out all domain events on the design board. This makes negotiating the scope of the next milestone straightforward. It’s a perfect occasion for developers to have a massive influence on planning. Here is a post explaining how to use Big Picture Event Storming to agree on a target scope in more detail.

I’ve written a lot about Event Storming in the past. Misadventures with Big Design Up-Front is a good starting point. (Note: My colleague Matthieu Tournemire and I have created the Event Storming Journal, a blog dedicated to demystifying Event Storming)

3. Play the built-in quality game

A close-up photo of a team playing the Built-In Quality Game. By getting the whole-team, and especially product experts, to experience the benefits of sound engineering practices, the developers's role in sprint plannings should increase
From the Built-in Quality Game under Creative Commons Attribution-ShareAlike 4.0 International License

Often, developers are absent from planning by sheer ignorance. Many business stakeholders ignore the impact of omitting some technical practices.

Nobody Ever Gets Credit For Fixing Problems That Never Happened explains this situation. It concludes that serious games are a way to get everyone more aligned. The Built-In Quality Game could be such a game. We invented it as a fun alternative to formal training. It lets everyone experience how investing in engineering practices speeds up feature delivery.

Here are two other games to raise awareness about technical debt:

A poster I created to explain people how to play "Catch the Moon" and experience what it's like to add new features in legacy code. Playing this kind of games with the whole team can increase the developers' role in sprint plannings.

Hopefully, these games should make business people care more about sound engineering. As a result, they should pay more attention to developers during sprint plannings.

The Built-In Quality Game is open source, and you can download all the material to run it from GitHub.

4. Agree and improve a whole-team test strategy

At work, many teams have the long-term goal of ‘inverting the test pyramid.’ Although a worthy goal, teams don’t necessarily know how to get there by themselves. Without enough collaboration, product, development, and quality experts were only optimizing locally. They need more coordination to tackle the problem as a whole.

The template Miro board for the Test Strategy Workshop we use at work. The workshop ends we drafting test-improvement initiatives to be prioritized in the sprint planning

We created and have now run the Test Strategy Workshop with a few teams. The goal is for them to embark on a test improvement journey together. It’s a multi-stage workshop that spans many short sessions. Here is how the workshop goes:

  1. Introduction to the topic.
  2. Homework and presentation of the different kinds of tests in the industry.
  3. Drawing of the industry’s ideal test pyramid.
  4. Drawing of the team’s current test pyramid.
  5. Collaborative “Test Strategy Canvas” to agree on how the team is currently testing.
  6. Solution Focused activity to define the next improvement to “invert their pyramid.”

Product and quality people take part in defining the next improvement. As a result, they are more likely to sponsor test improvement during sprint plannings.

It was also an occasion to learn more about our own tests. It was as if we climbed up a tree and saw the whole testing forest unfold before our eyes. (Mirna)

Even if some team members were already aware of testing techniques, testing best practices, this workshop gives the possibility to share a common vision between all the team members. (Patrice)

This workshop is Toyota’s Improvement Kata in disguise: it’s a long-term quest! Once a team delivers an improvement, they should re-run the workshop to agree on the next step! Every run will strengthen the collaboration among the stakeholders.

Tell me if you would like me to write about this workshop in more detail.

5. Address technical debt from a business perspective

In this talk, Jürgen De Smet presents a workshop to make everyone agree about how to deal with bugs. It uses bugs as the visible part of the technical debt iceberg. Its structure is close to that of the test strategy workshop I wrote about above:

  1. The whole team gathers to agree on how to classify and deal with bugs. Some categories of bugs will be fixed, while others will be parked.
  2. After a while, they meet again to analyze parked bugs. The goal is to identify a sub-system where refactoring would fix a lot of these bugs. 
  3. They then run a Solution Focused activity to agree on a small refactoring increment.
  4. They regularly go through the workshop to keep the momentum.

I have not yet tried this workshop with teams. Yet, Jürgen obviously did, and it looks promising enough that I mention it.

Call to action

Photograph of a rock climber nearing the horizon. Increasing developers' role in sprint plannings is a long-term endeavor. Each of these workshops should get you closer, one step at a time.

Are you coaching a team in which developers are the mere executors of the business people’s plans? In this case, give these workshops a try!

The first one might not create a revolution, but it will start to move the needle. As you run more of these activities, the developers’ role in the sprint planning should grow.

What about you? Please share your tricks to increase the developers’ role at Sprint Plannings?

Here are other related articles that you read to dig further:

I usually write about 15 minutes worth of reading per month. I won't transfer your email. No Spam, unsubscribe whenever you want.

As a gift for subscribing, you'll receive an illustrated mini-ebook "How to start a team coding dojo"!

Leave a comment