Data-Driven Sprints

The end of the year is a great time to make a New Year's Resolution!
2023 will be the year when you finally run Data-Driven Sprints.
Are you ready to uncover how fast you can actually sprint?

Get out Data-Driven Sprints - Cheat Sheet HERE

Transcript

So welcome everyone. Thank you for joining me today. I'm Noah from the Customer Success Team at Go Retro. And as we're approaching the new year, I'm really excited to talk to you, to us about a subject that is really important to me and I really think should be important to you as well, if it's not already.

‍

Hopefully it was because you registered to this session. So let's get started. Okay. So what are we going to cover? I'm gonna start with a tiny, really short, quick interview, a interview intro of who we are and what is our. Then we're gonna talk about resolution time right before the year ends.

‍

If you haven't done that already, it's time to look forward and, and decide how 2023 is really going to look like for you in your teams. Then we're gonna talk about the solution time, right? So we wanna define our next steps how we're going to win 2023. And of course, we're gonna have time for questions and answers at the end.

‍

But feel free if you have questions while I'm speak. You can already put them in the chat. I'll if I can see you and talk to them, talk about them while I'm talking, I'll get to that. If not, we'll get to that in the end. Okay. So let's get started. So who we are moving to the next slide. So at Acumen the group behind Go Retro we're a group.

‍

Data lovers engineers at heart. We support thousands of engineering groups in running their agile processes optimizing their sprints and fostering data driven culture as we are doing today. Next slide. So I created a poll. So today, sorry, let's start with that. Today almost everyone talks about data, right?

‍

But we were really curious to know who does more than just. We're talking to a lot of Scrum masters, product owners, dev leads and more. And we heard a lot of different responses talking about data. So I've collected this range that you can see here to from my conversation. So it's starting from the extreme, one extreme of people thinking that there's no need to talk about data.

‍

We know our team, we have, we, we see everything. It's a small team, whatever. The second thing is playing the guesstimation. We're trying. We're feeling it. Data is there, but we don't know what to do with it basically. And the other part is eating sprint data for breakfast. So let's look at the results.

‍

So these are the results that I've collected sharing my poll. And I think for me the biggest surprise was that there's a lot of, not a lot, but still people that don't feel like they really understand why they need. I'm wondering if it's related to the size of their team or the maturity of the team, but I think it's really clear.

‍

It needs to be really clear by now. That if you want your team to make it and you want them to scale, then data is definitely a key. Okay. I hear from a lot of people, and this is why, what pushed me actually to, to do the session today is that they don't know either where to get the data.

‍

or what to do with the data that they have or how to take advantage of it. So this poll really helped me focus on what I wanted to, what I wanna talk about today. If you're on the side that still doesn't think the data is important then I think you need to pay special attention today. And notice, right?

‍

I mentioned this is a range, right? You don't wake up one day and you're eating sprint data for breakfast, right? You need to start somewhere. And if you are in the extreme side, You're really not dealing with data right now. Just start small. Don't try to jump too high right away. Select one place, one data point.

‍

Start digging there. You'll see it's addictive. Moving on. Okay, so resolution time, right? So right before the new year, it's always a good time to reflect and to decide how we want to see ourselves as individuals as a team, as a company in the upcoming year. I think it's clear by now to everyone that 2023 is not going to be an easy year, right?

‍

We're finally, Feeling like we're over covid. I'm not sure if we really are. And we are right now facing a global recession, right? It's already here. People are starting to acknowledge that and it's affecting all of us in different ways. It's making a lot of companies get to the point where they either need to freeze hiring or even letting people go.

‍

And this immediately means that companies need to figure out how to do more with what they have, or unfortunately, what they have. All right. And you as Scrum Masters, product owners product managers dev leads you are the owners of the sprints and you're planning and you need to make sure that your team is happy on one hand, which is not easy when people are not feeling secure about their job as much as they were before.

‍

But also you want to make sure they're delivering right. You wanna make sure your team is getting to their goals showing their.  and it's definitely not easy, but we need to dig deeper and to find how to shine, right? How to make our teams shine and our companies shine, of course. We can't just keep doing what we were doing.

‍

And let me go to the next slide to talk about that part. So this is a quote I really love and it feels like it makes perfect sense here. Talking about running sprints, right? So if you're not familiar with this insanity is doing the same thing over and over again and expecting different results.

‍

Right. So running your sprints the same way you've been running them, not making changes, not understanding what needs to be changed is exactly sounds like exactly like insanity to me. We really can't and we really have to understand what's holding us back and what can we do to improve. And by the way, I always thought this quote was by Albert Einstein, but I just figured out, I just found out if it wasn't, but I'm not sure who's, is it?

‍

So what is our. Our goal sounds super simple is to deliver more and faster, right? We want to it sounds really simple, but it's really hard to do, right? But when you have data, things become more clear, right? So what do we want when, what we need to do? We want to improve predictability.

‍

We can do that by improving our sprint planning. We want to raise flags on time. And if you're monitoring your sprints correctly, that's a lot. You want to identify where to improve and how. That's what we have the retrospective for.

‍

So where are we gonna start with the sprint planning? So sprint planning is always challenging but to do better we need to make sure that we understand the true capacity. Available capacity, right. Of our sprint. And why do we need to do that? Of course, this is to make sure we have predictability, right?

‍

We need, if we're not able to predict what's happening in the sprint, what is it all for, right? So to do that, we need to acknowledge individual abilities. We need to identify different blockers and reveal sprint breakdown. Let's see how we can do that. So starting with acknowledging individual a.

‍

So each person on our team has their own velocity, right? Just to make sure I'm showing you what I'm to understand what you're seeing this is just our example of how you can do your sprint planning. Of course you can do that in many different ways. But here you can see in this column here, the capacity per developer per day.

‍

We're not measuring this necessarily. Create competition between people, but we need to understand the capa the capacity. And basically velocity is different per developer and it can have many different reasons, right? Either they're junior or senior developers, maybe they have different responsibilities, right?

‍

A lot of team leads usually produce less. Maybe they're doing a lot of there's team members that are doing a lot of reviews, which are taking a lot of their. So we need to understand, we need to understand it and take that into account when we're planning. We can't plan the same amount of hours or story points for each person, for each sprint.

‍

And we also later on, we need to understand the next steps. If the capacity is deteriorator or improving, how can we improve that and make sure, make sure we're maintaining that those identifying different blockers, right? So we need to also understand every spin can have different blockers, and we need to try as much as we can to understand those and take those into account.

‍

So examples for blockers or things that can reduce our available capacity for each. So first of all individual carryover, right? It's something that we need to take into account. You can see that in the column here. Again, this is just like a table of all of my team members and what's affect the total capacity that they have and what's affecting it and removing capacity from it to get to the point of understanding the actual available capacity per person and for the, the rest of my.

‍

So by understanding the carryover, right, when I'm planning, I already know at least. Not, maybe not the exact amount, but how much carryover each person has in my team. And it's something I really need to take into account. I also need to understand my vacations or holidays. So right now, you can see here Christmas time this calculator can bring your data for the, for the sprints.

‍

I just talked to someone yesterday that said she has team members from five different countries. So five different calendars. She has to always check when they have holidays. It's easier when someone else is taking care of that for. If you have PTOs for different people, you need to make sure you take that into account as well.

‍

Meetings can also be something that we might not think about or interviews, right? Maybe I have a few team members that are doing a lot of interviews which is a good problem, right? But I need to take that into account. If it's taking a substantial amount of their sprints, I need to understand they're not going to be working on their tasks during that time.

‍

A few other examples could be on-call or shared resources. Maybe we have some developers front end or backend, depending on how your team is built that is working for a few teams. And then you need to take into account that they're not going to be working with your team the whole time. Or the example I have here in my team is Joe, that three days out of the sprint is dedicated to a different team.

‍

So I'm removing those from his capacity.  and of course, unplanned work. Now, unplanned work is not something we can really predict, but we can show averages and understand around how many how much time of our sprint goes towards that. It's kind of like a buffer, right? We want to make sure we put this time here I'm using a default value of five hours per person.

‍

Most teams for most teams, it's not divided equally, right? So take that into account as. And the last part is reveal the sprint breakdown. So it's really understand, important to understand, okay, everyone knows the growth capacity is not what you're getting. There's the available capacity, but what's the difference between them is something that we need to understand and where does this time go?

‍

We need to create clarity. We need to be able to reflect, to share with the stakeholders what is the status, where is our time?  and then see how we can improve, right? If we don't know what the problem is, we definitely cannot improve it. Just checking if there are questions. Cool. Okay, so next part.

‍

After the sprint planning planning the sprint starts and then we need to start monitoring the sprint. We need to track the pulse of our team, so we want to ensure, just a second, sorry.

‍

Okay. So we want to really understand we know what is the real sprint progress, how does it look like, right? We don't wanna wait for the retrospective to be able to figure that out. Okay? We can't afford waiting for the next iteration to start making improvements and we having the, by having the right.

‍

We can try to understand it. It's really crucial. When you're running your sprint, you need to understand, run the word running. It's not just about like the action of running, right? It's also managing the sprint. And it's definitely your responsibility and you have a lot that you can affect by doing that.

‍

So we want to understand we have the right data. We wanna understand the actual versus expected progress. We want to make sure the priorities are aligned. We want to make sure we don't ha. Avoiding our bottlenecks, right? We are handling them correctly. Let's see a bit of how can we do all that?

‍

So again, these are just screenshots from Go Retro. You can have this data from any of your other product management tools as well. So what we need to know and to, to make sure we're looking at is first of all our burndown chart, but more importantly, when we're monitoring the sprint, I don't wanna just look at the burndown chart as a whole for the whole team.

‍

I wanna make sure I'm looking at individual progress so that we can help the team members where they're struggling and where they are. Right. And that's why even in the daily meetings, I recommend taking a look at that filtering this data per developer and see how is the progress right now?

‍

What is the concurrent work right now? So this is my status right now. For example, I can see that I have two block tasks. By the way, they, the sprint started and ended with their stuck. So I need to understand why that. I have two tasks that I'm working on right now and three tasks in review, and I need to understand, does that make sense that I'm reviewing three different tasks at the same time that I'm working on two tasks at the same time.

‍

I need to understand that. Also, I wanna make sure I know, do I have missing estimations? If I'm missing estimations on tasks, then I'm. My visibility is not as good as it should be, right? Same thing for lack of ticket updates. A lot of times we get to the retro, we look at the data and we see, wow, you know, there's something here that took so long to do or took so much time in review, and then they just, the team can just say, yeah, we didn't update the status.

‍

That means we're not, we don't have the right visibility, right? We're blind and it's something that we can't afford. I do see that there is a question now. The question is on the capacity calculator, so I'll get back to that. Sorry, I missed that before. So last part is the retro insights. We wanna make sure that we're sending the retro tackling what really matters.

‍

Okay. Just a second. So, so far up until the time when we got to the retro, we planned, we managed the sprint, right? And now is the time for the team to hear what are they thinking and how they're suggesting us to improve. And as important as it is to hear what the team is thinking and how are they feeling, and what they feel the issues are.

‍

Then we need to make sure that, you know sometimes those things are not really aligned with our goals or the actual issues surfaced from the data when we're looking at it real time, right? So, We need to understand it's important to take what, what they're saying into account, but it needs to come in the right framing and proportion, right?

‍

We need to get them talking also on the real issues and what the data is reflecting. Sometimes the team is not even aware of what the data is pointing at. So they won't be able to re raise it on their own. Many times they don't want to raise it or they're not feeling comfortable or they don't know how to do.

‍

and a lot of times just critical input from the team members is taken the wrong way, right? A lot of team members don't feel secure raising issues that are a bit difficult could be a bit criticizing of other team members. So it's, it's really hard. We need to really understand how we're doing that.

‍

When we have data again it's a lot easier. Data is not personal, right? So it's helping us to uncover real issues, no hard feelings. We can understand what our bottlenecks, we can understand if we had unrealistic estimations if we're misaligned on priorities. And when I say Miss land on priorities, it could be two things.

‍

On one hand it could be. The tickets we're working on don't have the correct priorities. Right? Maybe something is labeled as urgent, but it's not really urgent and that's why I'm treating it like it's not urgent. But on the other hand, it could be the other way around. It could be that I am not working according to the priorities of the tickets.

‍

Both are not good, right? We need to understand if we have an issue with that. If we are having misalignments. This is something I'm hoping I can catch while I'm monitoring my. But if not, it's something that we need to surface in the retro and see how we're fixing that, how we're addressing that in real time.

‍

And the last part here that I wanted to mention is discuss, discussing and tracking your improvement. And what do I mean by that? So, you know, we ha we, when we do the retros, The real goal, even though some people might, might forget about it is creating action items, right? The action items are the engine of our improvement, how we're suggesting that we try and improve for the next iteration.

‍

If we're not tracking what happens with that, then we're missing a big part of it here. A lot of times I see teams that are creating a really great discussion generating action items, but they get to the next part, the next retro they look at the action items. And we ask what happened with that?

‍

And we realize, oh, nothing happened. And this is really, really blocking our team, right? It's something that we really can't afford. We spent the time to try to figure out what to do, and we're just not doing it. It means we're not able to generate opportunities for the team to improve. So also something we need to check and look at the data of the action items as well.

‍

Let's see a few example. Of how we can raise data and how we can integrate it into our board or our retrospective basically to get the team talking. So a few data points here that we found that could be interesting for the team. So one thing, when we're not setting a goal for the sprint, it's really important.

‍

We need to make sure the team is aligned. We understands our goal. If we don't know what our goal is, we don't know where to go, right, where to look at. It's really, I. So this card is suggesting that we create an action item to basically set a goal, right? Really important. Notice, action items shouldn't all be assigned to the team lead or the person leading the retrospective.

‍

Another thing that we can see here, We can look at the sprint data the velocity average velocity planned versus actual. And the card is letting us know that we're planning 60% over our average velocity. While the benchmark is 20%. This is something we need to take into account as well, right?

‍

It's really important that our planning makes sense is relating to reality. Another thing we can see is look at what we worked on in the sprint and think and talk together. Does it make sense? So we can look at how much we were working on bugs compared to the stories compared to spikes. We can track how it was in this sprint compared to the other sprint, for example, if every sprint we're finding ourself working.

‍

20% of our time on bugs, and suddenly we have 40%. It's something we should stop and think and take a look at and, you know, try to figure out what happened, why it happened, and what we can do to avoid that perhaps. What else? So 12 tasks were left in, in review status. Anything you can do to avoid this extra carryover, right?

‍

So tasks that are being carried over between sprints have a really harsh effect on the team, first of all, and not just on the team. Teams. A lot of times they don't really realize that the sprint planning is sort of a commitment we're making for the business side. And if we're not delivering then we're failing with this commitment.

‍

So it's really important to understand that on one hand. Second of all test that are being carried over between sprint and sprint, a lot of times just stand to disappear, right? We put time into this work and then we're just letting it go. And that's, that's really And the third thing is that specifically if the task is being carried over in the real last parts of right before it's being delivered, it's really a lot of times just a matter of putting the right attention to it, understanding if we need to redivide the, the person or the per people are doing the reviews and get this bottleneck over with these are actually related.

‍

This team saw that after they took action items from seeing something similar. Their pending time, their, their average review sorry, the average time in pending review actually dropped from 95 hours to 53 hours. Now, you can say that 53 hours might be still pretty high, but it's a huge improvement, right?

‍

It has to be step by step of improvements. And we really need to make sure that the team, not just us, but the team understand what ch, what caused this improvement and how we can continue with this trend, right? We want to reproduce this improvement and continue on with it. If we don't know what happened, if it was just by chance that's not working with data, that's not gonna be sustainable.

‍

Other things that we have here. So, for example nine issues might be a lot that don't have estimations and that really hurt our predictability, especially when we can see that one of them took 16 days to complete. Imagine how much it's hurting our predictability when we have a huge chunk of our sprint that we can't, we're not taking into account at all.

‍

Right? Really something we need to understand how we can avoid. The last option, the last example I have here completed seven low priority bugs. While there are three highest priority bugs left unresolved. So was this planned? And expected? Usually it shouldn't be, like I mentioned before, it might be related.

‍

To misalignment with priorities. The tasks are prioritizing correctly, or the team is working on them not like the priority. And that's again, is really bad practice. It's something we need to make sure we're avoiding. So again, these are just a few examples. And you can decide how you want to present these to your team.

‍

A lot of times just showing data points and starting the conversation again from a real objective place can really, really help out. We do hover. You can see that some of these cards were brought by go retro joker. Basically it's a feature that crunches your data and puts it objectively into your board.

‍

But you can do that as well. Again, if you're not showing the author, right, you can see that some cards here have an author, some don't. You can control that and you can add these data.  And make that con start that conversation with your team as well. They don't need to know where the data came from.

‍

Well, who brought up the.

‍

Cool. So trying to summarize this presentation I was thinking how to summarize it. And I felt like there were a lot of words that kept repeating because I felt like, you know, they're so important. So I had to, I said I had to try something. I wanted to create a word cloud from everything I said and wrote for this presentation.

‍

And I had a feeling it would be helpful as a. I also felt like it was a really good metaphor for this theme. The, the subject we were talking about. I feel like a lot of times maybe I'll, yeah, let's do that afterward. So looking at the word cloud so we can already see improve and data and I identify and expect and decide and managing sprint and real data, right?

‍

We need to understand the actual data recession time, right? Planning, all of that and the time important, crucial. Bottlenecks versus feelings, right? All of this. So what I wanted to say is that I feel like it's a really good metaphor for working with data. At first, it all looks like just a big cloud of data.

‍

You don't know what to do with it. You don't know how to read it, you don't know how to approach it. But you need to take a good look, try to figure out what's important what's not, and see how you can you know, put action into it and improve. Now next slide is questions. So I'm gonna start with the question that we have here.

‍

So just wanted to ask how the capacity is calculated in go retro? Is it based on numbers, hours, or story points? Okay. So the, you know, let me just go back to the screenshot so you can, oh, sorry about that.

‍

So capacity calculator. So right here for this specific team, it's show, it's our, it's set to ours, so we're showing it as ours. You can define it as story points, and then it will be in story points. You can also make the decision per column. Cuz even if you're, cause if you're working with story points, it doesn't make sense to put PTOs at story points as well.

‍

Right. It should be days. We're able to calculate that and basically because we are converting the capacity per day for each developer, we know, just know how to remove one day of it. And that's how we're getting the calculation. You can decide as well for interviews, for example. Again, it doesn't make sense to put it in story points.

‍

If you can do this conversion, that's fine, but we can also do this conversion for you with ours as well. So hopefully that answered your question. Now while I'm moving back to the last slide of the questions, I'll wait to see if anyone else has any questions. And if not, I can click on the next one and tell you that lookout, because there's a cheat sheet that is coming when I'm, when I'm going to share the recording of this meeting.

‍

I'll also share a cheat sheet on how to work with the data. Basically a really quick summary of what we discussed and how you can start working with data. Up next, just so you know in January we're gonna have a really great hopefully scrum talk with Rachel. Rachel is an amazing agile lead that really, really loves data, and we're gonna hear from her.

‍

I'm gonna ask her a few questions, try to get, make sure that the audience gets the most out of her amazing brain, basically. So you're welcome to join us as well in this. And if there are no other questions that I would like to say, thank you everyone for joining me. As I mentioned, I will share this recording later tomorrow, I think.

‍

And hopefully this was helpful for you. Hopefully I'll see you again next session. Have a great day everyone.

‍