Becoming a Sprint Pro

We hosted Tali Gueta, GoRetro's VP or Product to discuss the challenges behind the sprint planning process, and how to help your teams achieved better predictability and increase delivery. Learn how to understand your team's capacity, improve your estimations and more, all while saving time and having fun.

‍

Transcript

Noa: Okay. Uh, hi Tali how are you today?

Tali: Good. I'm good a little bit.

Noa: Uh, uh, under the weather.

Tali: Under the weather, but I'm, I'm good. How are you?

Noa: I'm great, even though, yeah. I don't like the wintery feeling that we have here today. I'm doing good. I'm not really . Uh, great. So thank you everyone for joining, uh, us today.

Uh, I'm Noa Green from the customer success team here at Goretro and I'm very excited to have Tali, uh, here with me. Tali is our VP product, Tali. Hello. Hey, if you wanna introduce yourself.

Tali: Yes.

Hi. Um, so yeah, as no said, I'm the VP product here at Go Retro. I'm very passionate about everything related to.

Sprint planning and working with developers. I've been doing product management for eight years, um, and one of the things I like the most is sprint planning, so I'm really excited to be here and talk to everyone about the new sprint planning features that we have.

Noa: I'm really curious if we ask a lot of other product managers if they'll say that planning is also

Tali: something probably not.

It's, it's one of the hardest challenges, I guess, uh, for product managers. . Yeah, .

Noa: Cool. You wanna move to the next slide? Yes, of course. Yay. Okay, so we wanna start, uh, I always like starting meetings, uh, and webinars with icebreakers. So if you can open our icebreaker for today. Let's see what it is.

Okay. Oh, you're not the, you're not the owner of the board.

Tali: Yes. You need to open the icebreaker.

Noa: You wanna open just another one? We'll get a surprise, a different surprise. Yeah, of course. Yay.

Okay. So, How do you know that you're an adult? Ooh, t wow. You know, you're an adult.

Tali: Um, how do I know that I'm an adult? Um, I think having to pay my own bills, um, and keep track of them cuz like if I don't pay one of them, um, No one is going to remind me to do it. Uh, so yeah, I guess that's

Noa: the one I, I, I have to say that's exactly what went through my mind as well.

paying bills. I guess also maybe like, um, you know, when you're feeling like you're, you are older, like not like an adult, but you're already a bit older. Like Yeah, when I was a bit younger I could do this a lot easier. . Yeah. This is more like old than adult. Yeah. I think bills. for the best part of it. Like, not the best part of it, but the, definitely the thing that makes, lets you know, you're an adult.

Tali: I, I actually have another one. Um, having to cook to cook my own meals Hmm. Is also an indication that I'm an adult. Cause like

Noa: you can't, I feel like be in charge, being in charge of the meals because a lot of times I just order something. But yeah. If I don't do anything and I just stay hungry, then yeah.

Tali: Yeah. You, you don't want to live your life on take.

Noa: Yeah, that's true. That's true. I try, I try not to. Cool. Thank you. T And now we're both adults, , , but can you just quickly go back to Yeah. Okay. Thank you. So I wanted to share this specific board, uh, so that everyone's familiar with it. This is our feature request board.

Uh, and it's open to everyone, uh, to go in and I welcome all of you to go in and check if you have any yet. Thank you Sha Tali for showing us how you can get. Perfect. Uh, and so everyone can go in, add their own request. So if you have something that you feel like you're missing out of, go retro, just come here, add a card.

Or if you see that there are other cards that you also agree with, you can add your votes to it. You can already see we have a done column and we're moving away, stuff that we've completed to the dentist. You can also get updated, uh, what's happening with your request as well. Uh, thank you Tali. Let's move on to our webinar for today.

Uh, so what's on the. So I'm gonna do a quick intro about Go Retro and running your Agile processes in one place. Uh, then Talis gonna talk to us about the top challenges about managing and planning your sprint. We're gonna get to the main part of today and talk about, uh, understanding your team's current capacity and improving your estimations.

And we'll have time for questions and answers if anyone has questions. Uh, great. Thank you so,

Tali: all right. Yeah. Yeah. Let, let's dive in. Yeah. Okay,

Noa: cool. So, uh, so yeah, so basically, uh, go retro, uh, by acumen. So, uh, the team behind Go Retro is actually called Acumen, if you haven't known that, uh, so far. Uh, just a second.

Sorry about that. Uh, and basically we're a team of developers, uh, who are facing some of the most common challenges development, uh, teams have. So, like everyone else, we want to deliver more, uh, and faster. We sometimes over plan, we under-deliver. We don't always get the best action items out of our retrospectives.

Uh, and we wanna improve, right? So we decided to take action and the first thing we tackled, uh, was the retrospectives. Uh, and, but our vision was not to stop with retrospectives, right? We wanna create a space, uh, for development teams to manage all their agile processes in one. So, uh, already today you could have used, uh, go retro to run your direct perspectives.

You could also use our sprint monitoring to review your sprint and how it's going while it's running as well. Uh, and today you can also manage your planning processes as well with Go Retro, and that's what we're gonna talk about today. All right? Yeah. Ty, take us through the challenges.

Tali: Okay, so, um, in the past few months we've been discussing with a lot of product managers, scrum masters, and, uh, developer team leads that are all facing challenges when it comes to sprint planning.

And, um, we've been hearing all sorts of challenges. So to name a few. Um, sprint planning is a little bit all over the place. I have to chase my developers to put in estimations. I never feel confident in the meeting, or I always go into sprint planning, anxious. We always forget to take into consideration our carryover task, which makes us miss our deadlines, and I wish I was able to see in one.

In one place, what is the status of my sprints? So everyone is having challenges with this meeting and, um, this meeting also, and I'm talking about sprint planning. Um, uh, this meeting also has a lot of valuable. Sorry. It's very important for the company and for your agile team to be able to plan better ahead, make better decisions, improve and grow as a team.

So that's why there's a lot of weight on the shoulders of the person leading and being in charge of this meeting. Um, and when we dug deeper into this, we were able to. Collect three main challenges that we're repeating the most. So, uh, what stands in your way to make predictable sprints with excellent delivery?

Um, the three top issues that we saw was understanding the capacity for the next sprint, meaning how much are we actually able to fit into? The next sprint, getting your sprint backlog estimated. So not having to chase developers to get to get estimations, um, is a big challenge and finding the best route to achieve the sprint goal.

So how are we going to fit everything together after we know the capacity and after we have our backlog estimated? How are we actually taking all of this chunk of tasks that we have and putting them into one sprint?

Anything you want to add,

Noa: Noah? Uh, I think that it sounds like very easy when you say like, yeah, we just need to understand, uh, and estimate. Uh, and that's it. But you know, it's, a lot of people say, okay, we have to. Complete the planning, right? We have to just get through with it. Uh, but really missing the point that this is really the key to really improve, uh, not just your predictability, but really, uh, improve your delivery, right?

It's really, it comes in together. Uh, I think everyone knows that if you put a lot of stress on your team, maybe you're able to get more out of them in a specific sprint, but it doesn't work for the long run, right? We have to be able to understand what the team can actually. Uh, and continue to plan accordingly.

This gap between, uh, actual, uh, work and what we plan can be, can create a real toll on teams. Uh, so it's really important.

Tali: Yeah. The team's mental health, uh, exactly is very, very important. We don't want to overwork them, and we don't want to give them too much stress. Yeah, definitely. I

Noa: think we've both heard from, uh, together from, uh, from a scrum master, was it that mentioned that one of the problems he has that his team is actually trying to, uh, cover up like that they're not able to reach the goals because the goals are mm-hmm.

uh, to extreme and they're just overworking themselves and that's not where you want to because it's just, it's not a good long-term, uh, solution. Yep.

Tali: Exactly. Um, so now we're gonna dig deep into, uh, each one of these challenges, and we're going to share how we suggest, uh, to improve these processes. So the first thing is, uh, predictability and delivery.

How are we solving the capacity problem? So, When it comes to, uh, capacity, a lot of the times we hear developers or, um, team leads or, uh, product managers or scrum masters say, yeah, I sort of know how much we can actually fit in the sprint. Like I have an guesstimation, like I'm guessing in a sort of estimation.

Um, and I think I know how much each team member can do, but I'm not really sure about, so it's gonna be okay. Most of the times that doesn't work. Um, and we see all sorts of different ways, uh, that they try to cover or. Figure out that capacity number. So a lot of people we talk to use, uh, spreadsheets that are very complicated and require a lot of manual work to collect information from all sorts of places.

Uh, some of them calculate manually even in their head. We even talk to one scrum master who said that, uh, if she's tired that day and her calculations are off. Then she has nothing to do about it. Like her entire sprint is going to be relying on that number that she calculated when she was tired. And, uh, some of them just hope for the best and as not just, uh, shared an example from one scrum master that we talk to, it doesn't always work and it puts a lot of stress on the team.

Noa: Yeah, I think you really hit the point with the sort of, right, it's like, yeah, I sort of know there's 10 days in the sprint and everyone sort of does that and let's see what happens, right? So yeah, definitely what we're trying to solve is the sort of,

Tali: yeah. So how are we going to do that? Um, we wanna help you, the professionals to be really good at planning.

Uh, we wanna help you keep a healthy work environment where everyone is happy and not overwork, um, and not super frustrated by how sprints are going. We wanna help you keep your obligations to your stakeholders and, uh, if you say something will be ready by a specific time that hopefully it. Or increase the chances that it will.

And we want to help you plan a more realistic sprint and deliver faster with higher team motivation. So with that, uh, I'm happy to share our new capacity planner. So I'm gonna go back into my, uh, go retro accounts and I'm going to click on planning and choose capacity calculator. Here I can see my go retro team, and these are my sprints.

So I can click on, uh, create new Sprint to create the next sprint, which is sprint number nine. I can choose the dates, so it's going to start this Wednesday and continue until the 14th of December. I have my location and I have my estimation method. I can change it to story points if my team works with story.

And here I have my capacity calculator. These are my goal retro team members. So they automatically appear here. The working days are calculated automatically based on the, uh, days of the sprint, uh, if I had holidays during that, during that time, the holidays will also auto-populate based on your location and the dates of the sprint.

and I can go in and manually adjust, uh, PTOs and, um, how much carryover tasks, uh, each team member has or, um, if they're on call. So if half of their sprint is dedicated to being on call, I can just deduct half of their, um, estimation to being on call. I can also, um, Do the same for shared resources. So let's say Stacy is a backend developer that I'm sharing with a different team.

I can deduct half her. Oh, this, sorry. This is not too . Um, I can deduct, um, half of, half of our time to, uh, Sorry to being, uh, a shared resource. Um, and then I get here the total pair developer and the total for the team. I can see out of the growth capacity of the entire team, what I actually have available for actual development work.

And I have here a nice breakdown. how, what my time actually goes towards. So I can see that a lot of my time is going to, uh, carry over tasks or a lot are going to being a shared resource. And this can actually be a really nice way to visualize to my manager that my team is spending too much time on other obligations, which means that they don't have enough time to work on their actual.

Noa: Yeah, I think something that really pops here to my eyes is looking at the sprint capacity and comparing between the growth, uh, time and the available capacity. It's something that, you know, people always say, okay, I have eight hours a day, 11 days, and this is a toll I have. Right. But it really pops how much of a difference it is, and we all know that no developer actually codes for.

Uh, eight hours a day, but we still don't really take that into account and a lot of times we forget to take all these calculations. How much carryover do I have? How much time are we working on unplanned bugs, right? All these things, uh, really have a, an effect. And I think Tali, we can share that right now.

You've already mentioned that uh, holidays are coming automatically. The working days come automatically. Uh, you can already see the Jira integration sign on the capacity per day. Basically what that does is allows you to fetch the actual capacity, uh, for each developer and how much they're actually, uh, working on.

Yeah. Cause we do know that not all developers, uh, are able to, uh, get to the same amount of. Deliverability, right? Uh, every sprint or. Uh, but the vision is to bring more and more data. So soon we'll be able to fetch, uh, the carryover data from Jira as well, right? So actual, uh, data on carryover, we'll be able to bring in the unplanned bugs data.

Uh, and the idea is to bring data from more and more, uh, integration. So from your calendar or your HR systems, we'll be able to bring PTOs, uh, and times you spend on meetings. Uh, maybe on-call will be from, uh, systems like PagerDuty and stuff like that. So you'll have to do, uh, less and less manual work and more get a in, even better, um, an accurate, uh, time of what's your total capacity.

And you can see here that you can see per developer, if that makes sense to you. And also the total, uh, capacity that your team has for this sprint. Yes. Uh, what else are you, did we not mention here, Talia, anything?

Tali: Uh, no, I think we covered everything. You can use it with Jira and without, so even if your team does not use Jira, you can still manually input, uh, all the, all the different information.

Um, and another update that's coming soon is that you'll be able to add your own. Uh, columns. So basically if, um, meetings are not relevant to you, but you have something else that is, you'll be able to remove this column and add your own, uh, based on what works for your team, you'll be able to configure everything and make it work based on the way your team

Noa: specifically.

Right. And I think maybe something we didn't mention is that the capacity calculator, uh, helps you more and more the more you use it, right? So the first time you'll use it, you might not know exactly what to put, uh, under each column or, or basically just use it like with the most basic functions, and then you'll be able to come after the sprint and see what really happened and you'll be able to learn and adjust from it and get even more and more accurate.

Uh, so that's really cool. Great. Thank you, Tony. Yeah.

Tali: Great. So, uh, let's continue. So after we figured out, um, capacity, the next thing we wanna do is to get quick and unbiased estimations. Um, so how are we solving it today? Um, We know that in uh, theory we want developers to give their own estimations to their own tasks.

Uh, but a lot of the times we get to a point where, uh, we don't really have estimations on a tasks or that developers are not really junior developers, at least most of the times, are not really great at giving estimations because they're not yet familiar with everything they have to take into account.

Um, And, uh, a lot of the teams even say that, ah, yeah, we're not that great with estimations, so we just don't, don't bother. Um, We, um, see some teams that, uh, the dev leads are actually the ones giving estimations, um, which is not really ideal because, um, the whole point about estimations is that each person is going to estimate how much it's going to take them and not the very experienced dev lead that knows the system and, uh, the job really, really well.

And some teams actually have like a dedicated estimation meeting, um, where the entire team sits and talks and does the estimations together. This is very time consuming and we also know that developers don't really enjoy doing meetings. Like everything that's out of just sitting and doing their own work, uh, feels like not a thing they wanna do.

So adding another boring and long meeting is not really the thing that. Would wanna do .

Noa: Right. Basically. So we're taking what we're doing with, uh, the retrospective meeting, right. Making it a lot more fun, uh, collaborative, uh, engaging and trying to do the same thing, uh, with the estimations process.

Tali: Yeah, exactly.

Sorry for the sirens, apparently. A lot of ambulances this, this hour. All right. So, uh, to do that, uh, we developed a tool that will help team understand the complexity of a task that will make estimations more realistic, will, uh, be a good learning opportunity for those juniors who need to learn from those more seniors, developers, and will also actually be fun, um, and some sort of a game environment.

For teams to use. Um, um, um,

Noa: Yeah. And I think this is also a great opportunity, learning opportunity, not just for, uh, junior developers, you know, to, to hear how other people are estimating and learn from that, but also for even you as a team lead or a product owner, right, to see how the team is handling it, how do they feel about the task, and really, really figure out the complexity of the task.

I think when talking about it together, you can really get a much better, uh, estimation and understanding of the task specifically. So it's easier to work on it later, but also of the estimations. Yeah, ex.

Tali: Exactly. Thank you Noah . Okay, so, uh, with that, let's talk about our poker plan, planning poker tool. Um, so to get to the Planning poker tool, you click on the planning and choose planning poker.

I'm going to create my new sprints. Um, I can choose my own display name. So if you want to have an anonymous game, uh, you can also do that. This way I can choose my voting system. So if we're using fiche, if we're using t-shirt size, uh, if we just wanna use sequential, but soon you'll also be able to actually create your own, uh, voting deck.

Um, You can make sure that this is adjusted to the way your team does estimations, and I'm just going to click on start game. To invite my team members, I only need to click on invite members. This copies a URL to my clipboard that I can just share over Slack teams or whichever tool your team uses. And now I'm going to import my tasks.

So, uh, to import from Jira, Azure, DevOps, or any other tool you use, just export as a C S V, uh, your list of tasks, and then. Import them inside and it will automatically create your tasks for the estimations. Uh, now I can see that Noah joined my game. So we can actually start. So I'm going to choose a card

Noa: before we start, Talia.

I just wanna make sure it's clear right now you have to manually bring your issues. Right? Uh, but very soon we will also have, uh, the Jira integration here where you can fetch your, uh, data as well. Yes.

Tali: Correct. Uh, thank you Noah. So, uh, let's choose, um, the ability to add tags to cards, uh, which is a feature that we recently launched and it's very cool.

I recommend that you go check it out in the retro boards. So I'm going to click on vote now, and now I can choose. Personally myself, what is my vote? So what I think the estimation of this task is, so I think this task is a three story point task. I can see here that Noah already voted because she has like the green check mark and Daniel just now voted.

So I'm going to vote as well and the cards are gonna be revealed and we see that the average result is three. So this is a good opportunity for us to have a healthy discussion as a team about why we gave that estimation, why we think it's a three. Why? No, I think cause it's a five. Um, go over the things that maybe some of the of us didn't think and then reach a decision as a team.

What the real. Result is, right now it's average, but I could actually go to the, uh, settings of my game and change it to be either the median score or the consensus score. So if you, if your team prefers something else, you can adjust that as well. Then we can re-vote or we can

Noa: just move on to the next issue.

Right. And just, uh, something that also is important to mention. I think that, uh, so the first part where we are voting, uh, alone, right? So we understand that we can talk about the, as we can see the description, we can see what we're voting on. And each one thinks a alone, right? And puts their own vote. So we're not biased.

We can see what other people are voting. We don't know what they're doing. So we can put what we're really thinking, uh, You know, be worried and what Tali mentioned in the beginning. Also, if you want your team to have full anonymity, they can also just put in whatever name they want, all be on the same name, right?

And then, because at the end you, you do reveal the, the results and you do see what everyone votes. Uh, but it is important to afterwards have the discussion to understand why are we seeing differences if we are seeing differences. Yep.

Tali: Uh, then when you're done, you can export everything to C S V and soon we'll also have that Jira integration and then not talked about where the estimations are going to be sent to your Jira automatically, so you don't have to then manually go and update 30 tasks in Jira as well.

Um, did we cover everything? No. Anything else?

Noa: I think so, so basically, again, like Tony mentioned, uh, we're, we're, we have an opportunity here to make this task a bit more fun, a bit more collaborative, and try to really not just make it more fun, but also most make the most accurate estimations and have a better understanding of the tasks we're about to tackle as a team.

Yep.

Tali: All right, let's keep going. So, after we were able to, uh, understand the capacity of the team and understanding the estimations of our task, this is where, uh, everything comes together and we wanna maximize the predictability of the team. So the next thing we're building, uh, that we hope will be available soon is a task assignment tool.

So, sorry, um, in this. You'll be able to see the capacity of your team, the estimations of your black logs, and be able to actually build the puzzle of your sprint. You'll be able to, um, assign tasks to specific developers, see how their capacity changes,

Noa: sorry. Yeah. While tally is, uh, very over this, I can say that a lot of people we talk to also say, okay, I understand the capacity, I understand this emission, but some tasks can only be, uh, solved by specific people.

Right. Only specific people from my team can actually answer them and work on them. And that's why it's really important to not just say, okay, we have these, uh, estimations and we have this capacity, but we actually have to build the sprint and make sure we understand who does what and when.

Tali: Yes. And, and actually get a.

A realistic visualization of can we actually fit everything or are we, um, uh, do we have too much planned? Do we have too much on a specific developer? Are there any. Uh, co-dependencies between specific tasks that this developer can start before this one finishes their own tasks. So all of that will be available in the task assignment, which we're really excited about.

And if you want, uh, to learn more about it, hit up Noah later and she'll be happy to share more with you. Yeah,

Noa: definitely. And, and also something that I think you mentioned previously, but we didn't talk too much about it, uh, is that the planning process, uh, has a huge. On our stakeholders, right? We are basically, uh, making like a pro a commitment to be able to deliver something to our users, to the stakeholders, right?

Uh, and if we're not doing that, it's not just about our team and the development team and what's happening there, and if we're upset or motivated or not, there's more at stake here. And it's really, really important that we are able to predict, uh, and deliver as well. Yeah.

Tali: Yeah, I mean the bus, our business is relying on it, uh, that we are able to hit our goals on time, um, and get that perfect quarter or perfect

Noa: here.

Yeah, I think we had in one of our scrum talks then I had, I think it was David, uh, Farra that mentioned that, um, uh, Um, I hope I'm not confusing who said it, but, uh, that agile is basically a win-win situation, right? Uh, you're able to, uh, improve, you're able, your team is happier, but you're also able to create more value to, uh, your customers make more money.

Everyone's happy at the end. Yeah.

Tali: All right, so it's question time.

Noa: Great. So I think one of questions that we, we did see, uh, is if we're also planning on having, uh, more data in into the capacity calculator. I think we've already answered that. Uh, talking about other integrations. So right now the integrations, uh, will only work with Jira, uh, Tali.

Do you have any plans to make, uh, this integrations with other tools as. We hope so.

Tali: Uh, if you do want that, please let us know. We'll be happy to prioritize your platform first if you just let us

Noa: know. Exactly Right. So if you remember, we've shown the, the feature board, uh, the request. We've seen a few other, uh, suggestions there for other integrations for our sprint monitoring, uh, because we also integrate with Jira there.

But if you have any other integrations you'd like to see, please us, let us know or make sure to vote on the ones you've seen there that you want. Uh, the more votes, uh, there are, the better chances are we're, we're gonna do that for you, . Yeah. Okay. I, I think we've covered, uh, the questions, the other questions that we had, so, so that's great.

Okay. Okay, so up next, so, uh, next month in December. Hopefully some people will not be on vacation and will be able to join me. Mm-hmm. , uh, for the New Year's resolution at webinar, we're gonna talk about, uh, data-driven sprints. Uh, so we've talked a bit about, uh, planning right now and how you can improve it with, uh, adding more data into it.

Next time we're gonna talk about how to, uh, manage and run your sprint, uh, with data and hopefully make it a lot more successful. Uh, so, uh, we'll send the invite, uh, and registration link for that as well. Hopefully I'll see you there as well. Tali, you're also welcome. Come to join me. Of

Tali: course you will.

not gonna miss it. Yay, .

Noa: Uh, thank you Tali. So I think we are done for today. Thank you Tali for joining me and helping, uh, show the vision and what we already have. Uh, thank you everyone for joining us. We would love to hear your thoughts once you basically now go ahead and try it out. Let us know what you're thinking, what you're missing, what you love.

We'll, really happy to hear from you.

Tali: Yes, have time to talk to us even, uh, we'll be happy to hop on a chat and. Learn more about you, learn more about your team, what your challenges are, and see how we can help you and your team become a better agile team. Yeah, I

Noa: think it's important to mention everything we built here, we built out from what we've talked from conversations we had with users.

So if you want us to take your opinions as well, please, uh, we'll be happy to meet. Yes, thank you everyone. Have a good day. Thank you T.

Tali: Thank you, Noah. Bye bye. Bye.