Current Episode

Episode 3:

How do you make sure your team has time to make the improvements they identify in their Retros?

Does your team identify process improvements in your Retrospective then find it hard to make time during the next sprint to actually implement the improvements? You’re not alone. In this episode I’ll answer Cheryl’s question by suggesting 3 steps to help combat this issue.

Like the podcast? I’d love it if you’d take 60 seconds to rate it in iTunes.

Mentioned in the show:

Practical Estimation:

Do you have a question for the show? Want the show notes or transcript?

Leave a Reply

Adam: Welcome to Agile Answers. I’m Adam Weisbart, your Certified Scrum Trainer and agile coach. Every week, I get your questions about Scrum and agility, and I answer them, here on Agile Answers.

Today’s question comes by way of Sheryl Lacey. Her team identifies new ways to improve every retrospective. The trouble is, once they get into their next sprint, they seem to have a hard time actually saving time to implement that change. Maybe you’ve fallen into this trap too. I know as a new Scrum master, I was often in this trap. My team would identify great ways to improve. And then for some reason, during the sprint, we would run out of time. We wouldn’t actually make that improvement. Let’s listen to her question and see if there’s a way we can help her out.

Sheryl: Hi, Adam. My question is regarding retrospectives. My teams are always eager to discuss what they could have done better in the previous sprint that we worked on. Unfortunately, when the next sprint starts, we often don’t have time to actually work on any of those improvements because we’re faced with deadlines and other challenges come up during their actual sprint that prevent us from focusing on making those decisions. And even against my attempts to actually try to use write-up user stories and add them into, we use Rally, I’ve been asked not to. What have you done in those sorts of circumstances to try to put aside some time for the developers and the testers to work on those improvements?

Adam: Sheryl, first of all, I want to thank you for submitting a question. Let’s see if we can dig into this little bit. Well, the answer is actually pretty simple, and you’ve probably already tried this. But just to state the obvious, the first thing you need to do is make time during the sprint to address these things. I bet you’re doing that, but you’re falling, probably, into the trap that many of us fall into. So the first thing I would do with my team is make a working agreement with them. “Hey team, it seems like we have these come up every sprint. We figure out ways to improve moving forward, and then for some reason, we run out of time. So let’s make a working agreement that moving forward, we will save some time and make sure that we address these things.”

Now I personally, as someone who’s been through this many times, have a bunch of approaches that have worked for me and for other teams. But I wouldn’t actually prescribe one to your team. I would say, “Hey team, we keep running into this issue. How should we go about fixing it? It sounds like we need to reserve some time, but past that, I’m not sure how we would proceed. What do you guys think?” When in doubt, asking the team what they think is amazingly powerful and useful. I think that your team, through a little brainstorming session, will come up with some ideas.

I’ve had teams that they decide, “Well, we don’t want to start addressing this issue in the first day of our sprint. We figured out a way to improve, but frankly, we want to get underway. We want to start building some momentum again. So those teams have decided, like halfway through their sprint, they’re going to spend a bit of time making those improvements and planning that into their sprint then. Your team might decide to do it at a different time. The first thing I would do is start by asking them, “Hey, when would it be best for us to manage this thing, to work on it?”

The next thing I would do is you mentioned that you were getting some resistance, but you don’t mention who from, of adding these items to JIRA. And I would actually not even bother adding them to JIRA. I think the idea of keeping them visible to the team is essential, but I think that you should make a big, visible sign and put it somewhere besides JIRA. I put it up in the team room, if you’re all in the same room. Or if you’re spread out across a couple locations, maybe as Scrum master, put something together that is a little PDF or whatnot that you can give to everybody on the team, email it to them, if you’ve got some people working remotely, for example, and have them print it out and put it up in their work area for this coming sprint. “Here’s the thing. We agreed that we’re going to work on…” And it keeps it big and visible.

So the number one thing that has helped me, especially help me as a new Scrum master as I mentioned, we would fall in this trap very often when I was with my new Scrum team initially. And the biggest fix that I found for that was just to keep the thing visible, not locked away in JIRA and not forget about it, but actually make it visible in our work area, so I would do that.

So those are sort of the easy answers to your question. Now, I think it’s probably worthwhile to look a little more deeply into this. Now, the things that I have seen stopping teams on an organizational level is organizational pressure. The team comes up with a commitment for what they’re going to work on this sprint, and because they’ve reserved some time knowing that they want to address some impediment that they surfaced in the last sprint, they don’t pull in as much work as maybe they did in the sprint before or the sprint before that. And they get some sort of organizational pressure, either through the product owner, or if you’re a new Scrum master and are not great at protecting your team yet, maybe they’re even getting it from you. And so the team starts not doing some of the work they have all agreed they were going to work on.

If the team is getting product backlog items from the rest of the organization, those are very visible to the whole rest of the organization. The thing that’s not really visible to the rest of the organization are these process improvements the team has identified they would like to work on. So they think, “Well, we’re getting a lot of pressure, so we might as well focus on the things they’re expecting us to deliver, and we will ignore the things that we know are important to our process, we know they’re important to the organization improving, we know they’re important to our code base, but nobody else really knows about them at the moment. So we won’t just work on that this sprint and we’ll get to it next sprint.” And next sprint rolls around and the same exact thing happen. We have to put out the fires. We have to deliver the features everybody’s clamoring for. And so I suspect, if you’re like most organizations, this is happening with you as well.

And so what you need to do is make this impediment or this process improvement you have decided to make visible to the whole organization. And I would do that by starting with the product owner. We’d have a conversation with the product owner explaining why, if they don’t do this, if they don’t make time for this, even though all these other features are very, very important to our product, the team will not be high performing. The team will not continue to keep improving their process every sprint, because they’re not able to.

So I make it visible through the product owner and have the product owner evangelize that to the rest of organization, explain why this sprint and for their release forecast, for example, we may be doing fewer features than maybe we’ve done in previous releases. And as a product owner, I’ve decided that that is fine. In fact, I think it’s required for the health of our product and for the health of our team and organization. So I’m going to spend some of my money, some of the budget for this sprint and for the next one and the one after that, making these process improvements. So I would get your product owner, if they’re not already, on your side. And if they’re already on your side, I would give them the job of evangelizing this to the rest of the organization.

The last thing that I will say that might help your situation is perhaps the estimates you guys are putting on work is not particularly accurate. I’ve certainly seen a lot of teams run into this. Heck, as a Scrum master on working with new teams, I run into this. And I really recommend getting good at estimation, and not because the numbers of estimation are all that important. I actually don’t think they’re massively important. What I think is important about the estimation process is getting everybody on the same page about what is to be built and how we’re going to go about building. And when I say everybody, I mean everybody on the Scrum development team.

My favorite way to come up with estimates is a game called The Team Estimation Game. It was put together by Steve Bockman. And if you’d like to check out the format of it, you can get his book off Amazon. It’s a Kindle book, and it’s called Practical Estimation. I’ll put the link to it in the show notes, but the thing I like about his approach is that it’s amazingly simple. It’s easy, and it’s actually even kind of fun. And I have certainly sat with teams through The Team Estimation Game and gotten through 30 or 40 product backlog items very, very quickly, and pretty darn accurately, after some practice. I’ve not had the same practice, really, with Planning Poker. I found that to be drawn out in some cases and many arguments seem to ensue. But the practical estimation that Steve Bockman has put together in his book, Practical Estimation, I have found to just be amazingly useful for teams. They enjoy using it, and if you’re estimates are better, you’ll be better at reserving time for working on these impediments you’re surfacing in previous sprints.

So just to review, make a team agreement. As a team, you’re going to agree to tackle these items that you are surfacing in your sprint retrospectives. And frankly, if you’re having problems conquering all of them that you identify, maybe just start by agreeing that you’re going to identify one per sprint and focus on that. Secondly, make that thing visible in some physical way to your team on the wall. Don’t trap it in JIRA. And then make it visible to the rest of the organization and let them know why you’re making those sorts of improvements.

I’ll give the one caveat on that last step. If it’s an item that your team wants to keep private, it’s some process improvement that they don’t want to share with the rest of the organization. That is their purview. They are welcome to not share it with the rest of the organization. So in that case, you don’t have to make it visible with the rest of the organization. Though many of these teams will feel totally fine sharing with the rest of the organization, and in that case, I would have the product owner have those conversations, help educate the organization about what they’re working on m, which includes both building new features and improving our process as a team, so we can help our team kick butt in the long run by delivering software quickly and often.

I want to thank you for submitting your question, Sheryl. I hope the answer was helpful. And for having your question featured on the show, you’ll get a pack of my Agile Antipattern Cards which can be used for retrospectives or just in the day to day operations of your team, helping you guys surface organizational and team antipatterns, and tackling them, as long as you set aside the time tackle them down the road, I guess.

If anybody else has a question you’d like answered here on the show, you can go to, that’s And there on the home page, you will find a little widget were you can record a message that I may answer on a future episode. If it gets answered, not only will you get a great answer, you’ll also get a great pack of Agile Antipattern Cards.

If you’d like the show notes to this episode, along with the link to the book I mentioned, visit, and right there, there’ll be show notes. You can download the transcript. You can click through to get the book that I mentioned, or any of that good stuff. I want to thank Podington Bear for the music that backed this track and thank all of you for tuning in.

Until next time, stay agile. Never change.

Past Episodes

Episode 24:

What should we do instead of painful “Annual Planning”?

Episode 23:

Agile Virtual Summit Preview: Lyssa Adkins

Episode 22:

How do we make sure we have cross-functional teams and why does it matter?

Episode 21:

What agile practices can you recommend to our game development studio?