Combining Scrum With Data

How can you use data to increase the value created?

“In God we trust. All others must bring data.” — W. Edwards Deming

Deming is considered the father of quality. During his lifetime (1900–1993), he transformed how engineers approach quality. One thing intrigues me, however: the above happened before the internet was even born, and Deming was adamant about the use of data. What would he have done with all the endless possibilities we have now?

Our challenge today isn’t getting data, but knowing when to use what. Data alone isn’t enough. It goes from transforming data into information and then into insight. Connecting the dots is magic.

Imagine a world where you could have any data, qualitative and quantitative. How would you use it to create value faster?

Let me share some ideas on how to combine data with Scrum events.

Backlog Refinement

It disturbs me that backlog refinement isn’t an official event in Scrum. It’s only mentioned that teams need to refine their work, but this openness doesn’t provide enough guidance, and teams struggle to have valuable refinement sessions.

I take the refinement as seriously as possible. It’s the moment to understand the problems and their constraints. The refinement is a great moment to bring data into it.

Here are a few examples:

• Prioritization: Choosing what to bring to refinement requires decision-making. Knowing how many customers are impacted by a particular problem is a good way to achieve that. You can use it based on analytics, observation, or interviews. Of course, confidence and validity change, but it helps you to know whether customers care about it.
• Shaping the why: Bringing problems to solve isn’t enough. You need to explain why solving specific problems is worthwhile. For that, you can share interview quotes or data, and present the importance of the problem. For example, 3 out of 10 customers abandon their cart despite having products there. How might we change that?
• Success criteria: By knowing the why behind the problem, you can define what success looks like and build your solution ready to measure the results.

Sprint Planning

The difference between Agile and Waterfall happens during Sprint Planning. Data can save you from the hamster wheel trap.

Let me be clear about what Sprint Planning isn’t:

• Delivering a set of features unrelated to each other
• Implementing solutions defined by people who didn’t talk to end-users

Sprint Planning is the moment to set a goal for the next cycle and commit to it. You may read this and say, “I cannot set a goal because I have too many things on my plate.” Using data properly can change that.

Good or bad, you may be following an objective. That may be a key result, a Product Goal, or a roadmap milestone. The most important is having a measurable objective and then continuously measuring its progress, and the magic happens when you review the outcome and reflect on what could put you closer to the ultimate result. Example:

• Objective: Increase retention rate by 10% by the end of Q2 2023
• Current status: Retention increased by 3,5% 
• Reasons customer drop: 50% low usage frequency, 25% higher price than the competition, 25% diverse reasons

As a Product Manager, you could bring this data and collaborate with the team in search for options to act upon it. You may not have a solid Sprint Goal, but you could have a direction based on data because you’d know why customers leave your platform, and your objective for the quarter is retention.

Daily

Synchronizing the day towards the Sprint Goal is highly important. Although the Daily Scrum is highly operational and focuses on progressing, bringing some data wouldn’t hurt anyone.

If you’ve read some of my posts, you know I’m not a big fan of burndown charts, but I’m a fan of progress. What I like doing is making problems clear to accelerate solutions. Common problems happen when teams get stuck with their development process, for example:

• Code review: Four eyes principle requires every task to be code reviewed by at least one other software engineer. Yet, sometimes this takes too long, and people forget about things.
• Quality assurance: Some teams separate quality assurance and would have someone dedicated to it. What’s important is knowing how fast things are progressing.
• Usability validation: Similar to quality assurance, some teams would opt to have a dedicated product designer or similar role to test the usability of what the team created.

The problem starts when nobody knows how much time they waste with the ping-pong effect. Sooner or later, the team starts doing a little waterfall inside their Sprint. Ideally, it goes in a more natural flow. But life isn’t always ideal, so we’ve got to deal with it.

Bring data related to lead time and let the team know when the current Sprint is derailing. Scrum Masters or Agile Coaches are responsible for bringing the problem to the table and letting the team solve it.

Sprint Review

Do you want to bore your audience to death? That’s easy. Just talk about the last Sprint output and ignore everything else.

The Sprint Review is a working session, not a presentation. A better way to deliver value is by connecting the dots and creating a storyline.

Share how the previous Sprints contribute to the objective and how it’s impacting the desired metrics. Then, share what the current Sprint results aim to achieve and share how you will measure it.

Show, don’t tell.

Sprint Retrospective

Step back, inspect, and adapt. Do you have a better moment than that to use data in your favor? 

The outcome of a great Sprint Retrospective is becoming a better team. To enable that, you could use data to identify opportunities. Here are some that I like using:

• Sprint Goal achievement ratio: Evaluate how many hits and misses you have. Reaching every Sprint Goal is a sign of playing safe, and missing half of them is too aggressive. It’s essential to find balance.
• Sprint carry-overs: How often does the team carry something over from Sprint to Sprint? The more, the worse.
• Team health check: I recommend quarter team health checks, comparing results and defining actions to improve collaboration.
• Actions: How many actions did the team commit and achieve over the last Sprints? Setting actions isn’t enough; achieving them is what matters.

You can be creative with data. Think about what would help the team uncover opportunities to become a stronger team.

Final Thoughts

Everything in excess is bad. Don’t overload the team with data because they won’t know where to start.

Finding what’s enough is challenging, but reflect on what you’re aiming for:

• Direction: Search for data that show opportunities
• Progress: Connect your output with desired outcomes
• Team growth: Reflect on the team activities and metrics

Deciding what not to share is even more important than deciding what to share.

It’s easy to bring all the data you have and get the team paralyzed, and it’s hard to find the data that moves them. Yet, that’s your job :)