Co-Pilot with JJ Sutherland - More Than a List: Using the Product Backlog to Drive Long-Term Impact

Most teams treat the product backlog like a to-do list. JJ Sutherland, CEO of Scrum Inc. and co-author of Scrum: The Art of Doing Twice the Work in Half the Time, says it should be so much more. In this episode, JJ joins hosts Diane and Erich to break down how teams can use the backlog to set, own, and stay aligned to long-term priority goals — and how to make those goals visible to everyone, from your daily check-in to your board of directors. Whether you're leading a software team, a nonprofit program, or a community initiative, you'll walk away with practical tools to turn your backlog into a strategic engine for lasting impact. 

Evolving your work, accelerating your impact

Transcript

SPEAKER_01 0:00

All right, everybody, welcome back to Agile Driven Impact. Today we are in for a treat. We have a co-pilot episode for you. And what that means is that we have a guest who's hopping into the driver's seat with us. And today it's JJ Sutherland, the CEO of Scrum Inc. Some of you might know Scrum Inc. as the organization founded by actually JJ's father, Dr. Jeff Sutherland, who's the co-creator of Scrum. JJ has an incredible amount of expertise and experience in agility and in Scrum, working with organizations literally around the globe, across a whole bunch of different industries, software banking, nonprofit stuff, healthcare. It's a really long list. And so we're super excited to have JJ here to think about different ways that that experience helping teams adapt to change, accelerate value delivery, how can they use Scrum and agile ways of working to help build better people, better teams, and a better world. So JJ, thank you so much for being with us today.

SPEAKER_00 1:07

Thanks so much for having me.

SPEAKER_01 1:09

Yeah, we're super excited for this co-pilot episode.

SPEAKER_02 1:14

Sure. You know, I've I've known you for a long time, JJ, but I know. Both of you two for a long time. You know, your path to where you are today, uh, you know, it went through being an award-winning correspondent and producer at NPR. Um, to me, that's kind of a fascinating journey. I wonder how does your background in journalism, where clarity and storytelling are everything, shape how you help other organizations communicate their long-term priorities?

SPEAKER_00 1:47

So I would say more than anything else, I was in broadcast journalism. So I was in radio, as you said, NPR. And the real thing that radio teaches you is deadlines. Is uh because I start out my career in journalism in local station in Boston where I had to do a newscast every every 28 minutes. And then you had to write it every 28 minutes. Doesn't matter. At 28 minutes past the hour, a red light goes on, and you better have something to say. And so that is, I actually think the most powerful thing that I've learned from journalism is how fast you have to be. And the deadlines are real. And as I uh tell my children so much that it really annoys them, so deadlines focus the mind. And what I have found, one of the things about Agile is that cycle of regular delivery on at pace. So whether you're doing a one-week sprint, whether you're doing releasing every day, if you're doing something you can do that, like some software companies releasing 10 times a day, 100 times a day, if you're Amazon. Um, and and so, but it's it's that really the learning of that cadence. And what happens in terms of the transparency piece you're saying is when you go live on the radio or you go live with your product if you're doing software or whatever you're doing, you really learn about whether you're doing it right, whether you're building the right thing, whether your story is any good, all that kind of stuff, because you're forced to show it to the world. And you're forced to show it to a very judgmental world, and one where if you get something wrong, the world will let you know. And and so it's the transparency is important because it says, are you doing the right thing? And okay, you but then if you're not, it gives you the chance to say, well, 28 minutes later, I get to do it again, and I can get it right that way.

SPEAKER_02 3:37

Right.

SPEAKER_00 3:38

And so that is what I find one of the, I mean, there's other things that transparency does, but it's really transparency to your customers, transparency to whoever's getting value from what you're doing, you know, whether it's you know uh clients at a nonprofit, you know, who are who are getting, you know, you're delivering value to, you're helping them with whatever you're helping them with, or it's you know, uh government service, you know, where you know, where like, for example, I renewed my license to the DMV today, did it online, and I could tell that they had Scrum teams behind there building this website because it was better than it was like last week. And it was just like, okay, they are delivering, getting that feedback, and that's what transparency gives you the most is feedback, whether it's from internally, from your coworkers, from your peers, from your management, or but most importantly, from your customers.

SPEAKER_02 4:29

Yeah, that's that's fascinating. It's actually a little different take on it than I thought I would hear, which is really cool. Um, you know, I think that the the idea that you had to put it out there each time and the feedback, and then you know, it had that must, you know, the fear had to be taken away, right? You had to say, okay, we have to release something. So here it is. And I think that's that's powerful, that that cadence driving it. Um, so I think you had something you wanted to follow up on this one with.

SPEAKER_01 4:55

Well, I was can you imagine if we started to tell teams that we're gonna have 28-minute cycles of iteration? I'm like, whoo, we're not gonna use that timestamp as our recommendation for folks, right? Because a lot of people are potentially new to Scrum or Agile that listen to our podcast. A lot of folks, JJ, you and I have talked when folks are just getting started, where do they start? And we've had that conversation before, but I have a different question for you about when people are getting started or learning about this idea. Um, what do you think that Agile ways of working, that the Scrum framework, what do you think is the core problem that they help organizations solve?

SPEAKER_00 5:32

Uh there's a few. So um, first is clarity of what you're trying to accomplish. Because one of the things that uh you could, if you were listening to it going on every 28 minutes, was that totally new every 28 minutes, or was it I'm just making up, and what's the sort of the longer term piece of that? And what really happens with you know an agile process is what are you trying to do? And you really need to be clear on that. And if you aren't, you learn to be clear because you're getting that feedback. So I was on with a pretty large customer this morning where they're doing a sprint review of you know, sort of there, they work, uh they have two week sprints, but then every 12 weeks, every quarter basically, they get together and you know, do a review with the senior management. And so that was the review today. And there is one of these grips, and these were like uh initiatives that the senior manager really cared about. There are four of them. They're like, these are top four priorities this quarter. You guys have agile teams, go ahead and do this. And one of the teams was uh ready to go at the beginning of the quarter, had a dedicated team. That's a big problem everyone has. You don't have a dedicated team. Yeah, and uh they you know were able to start doing it. But one of the teams, well, they said, Well, our first sprint will be pulling together the team. Well, that actually took the three sprints, and you're doing 12 sprints, and then they took another couple of sprints saying, Well, what are we actually trying to do? And so they showed up at this review, having really worked for about four weeks of the 12 on actually what the thing was. And the what was great was that team said, we learned, and what we want to tell the next group of teams that are gonna be doing this next quarter is to get that clarity of what you're trying to achieve, that definition of done. What is that? And that requires more investment than I think most people think about.

SPEAKER_02 7:22

Sure.

SPEAKER_01 7:22

Yeah, that makes a lot of sense.

SPEAKER_02 7:24

Yeah, that kind of brings me to a thought on uh many people that I work with, probably you as well, um, think of a product backlog as a task list, right? A list of items that we've got to get done. And a lot of organizations don't see it as maybe their roadmap to their strategy, right? And what they really want to achieve long term. So, how have you helped teams and leaders shift their mindset to see it as such, to see it as something that is actually their strategy? The strategy doesn't live in the PowerPoint, but it lives in the backlog. How do you help people see that?

SPEAKER_00 8:00

So, usually, so I think about this client. So they have this person, you know, they have like a three-year strategy goal, and they, you know, which is a little long, but you know, hey, some things take a while. And uh, but what they did is they say they wrote one sort of vision paper, which they iterated on a bunch. Like this took us a few weeks to get it done. And then they said, okay, well, how does that vision what we're what we want to do, what we want to deliver in three years? What is what are the strategies, what are the things that make that make that up to make that vision real? So then they have this plan. And then they say, okay, now that we have this plan of how we're gonna do that, it's a pretty big thing that they're doing. How does all our backlog fit into that? How does each piece of backlog feed into which part of the plan? And how does it help it deliver? And then how does that plan to deliver the vision? Is they check whether it's right. Because sometimes the backlog will change because you'll learn something like, oh, that thing that we thought was really important to do isn't actually delivering that plan that's supposed to deliver on that three-year goal. So we're actually gonna change it. And so the backlog, it's important, it's how do you get your vision into a plan or a strategy, then into what are you gonna do on Monday. Because that's but you need to connect all three of these. Because sometimes, like one group I'm working with, they make submarines. You don't make submarines in a year or three years or 10, right? They just take a long time. So they say, Oh, but there's no way we can cut that down. I'm like, yes, but what are you gonna do on Monday? You're gonna do something. And how about we just sort of measure your work? Like, you know, you're getting here, you're doing a submarine, or another client I work with does like apartment buildings or hotels, or you know, these things take a long time. They took years to build. But it's sort of like, okay, but how what is the part you're gonna be able to deliver that you can see whether you're learning from it in two weeks? You're gonna do something. And yes, it's not, you know, there's this hotel exam. I was down there a couple weeks ago, and you know, they can't make money from this hotel until the hotel opens, right? And that's a couple years. Like there's you know, hotels just take it, just takes time. But they were going at it when it would take, they thought it would take them five years. And they said, okay, well, what's getting in our way of being you know, getting down to three years? And a lot of that there they years of waste was all of these things in the system that Agile can teach you if you're constantly trying to learn, you're putting something out. So they would finish a room instead of just, oh, we're just gonna do the electricity, then we're just gonna do this. They would finish a room or a section and see whether it was right or not, and get that judgment of the world. It wasn't customers, obviously, but from the inspectors or the you know, the safety inspectors or the quality inspectors, whatever it is.

SPEAKER_01 10:57

I've never well now I've I don't want to get sidetracked by thinking about what a hotel build would look like with Agile and Scrum.

SPEAKER_00 11:05

I I'm gonna get down to the there's post-it notes on the wall, and there's product owners. You know, I walked around with one of the product owners, and oh anyway, I can if you'd like, I can go into that story. It's really fascinating. We're working on a case, so you know it's a company called Kayala, which is down in Guatemala City, working on a case study with them. I mean, again, like this is not a secret. We, you know, this is something I can talk about because they're we've done speeches at conferences and stuff with them. Um it's really cool. Cool.

SPEAKER_01 11:33

Well, and I think because, you know, obviously, nonprofit background, all things, race cars and other automobiles and things that move, right? Like the stories of where Agile and where Scrum work, it works everywhere, right? That's what we always all talk about. It works everywhere. But I think one of the things, we talk about the formal language, product goal, firmly established as language, again in the updated Scrum Guide. People understand long-term commitment. But then when you start to talk to teams where maybe you're introducing Agile or Scrum for the first time, they're like, so we don't make products, we serve people, we are selling hotel rooms, right? Like the word product goal as a phrase isn't always the label that's meaningful to a group when you walk in. So when you're thinking about teams that might feel like they're non-traditional, is there something that you do to help them see and understand what the product goal is, even if maybe they want to use a different label?

SPEAKER_00 12:34

So I see this part just about the part about the language for a second.

SPEAKER_01 12:39

Yeah.

SPEAKER_00 12:39

With teams like like uh my government customers are like, we don't have customers, you know, we don't have products, we don't have profit, you know. How do and and so uh when you're doing change in an organization, so one argument which uh I I'm not sure if I totally agree with you. So there's this guy who's a senior leader in the British government who I talk to about this all the time, and he I think he's right. Because I was like, well, let's take the scrum or agile language, because at one level, who what do we care what the actual words are, right? You know, these guys aren't reading the scrum guide. Like, why would they? You know, it's not that helpful to them. But but his uh point of view was let's change the language because if we let them keep it in their old language, that actually won't change how they think. Yeah, and actually having new words that are slightly off, like they don't quite fit with them, let help them get over that mental hurdle saying they are something new. And actually that rogue uh you know, that little road bump of you know, sort of like the initial one of getting the mental model, you know, to accept the new language, which a lot of them do now. This is in the Royal Navy, uh, it's caused people talking about backlogs and you know, sprint goals and all this other kind of stuff. But um, that's one argument. And then in another one of our customers, another very, very large traditional organization, they're like, we just can't do it. You know, we if we have a product goal or a product backlog, you know, we how about value or you know, this word scrum master, you know, and like these terms are just aren't gonna work. Like it's gonna be such a thing to go over. And I'm like, I don't care, call them German shepherds, I don't, I don't mind. But you know, we just care about what they're and into the scrum value, we care about what the accountability is. That's the the role of a scrum master, the role of product owner, the role of a developer is those are accountabilities, not necessarily job titles. So this needs to be done. Now, in terms of when people say, Oh, what's our goal, a product goal? I say, well, what is it that you want to deliver that? You know what? It's not gonna be done in a sprint. It's not gonna be done in three sprints. It might be done in six, or it might be done in a hundred because some things like building a hotel just take a while. So, but what is that thing? Sort of like you have that vision, and then you go up to that plan, and what is that thing that you're making this delivery? And it could be a service, right? You know, um the so like what's the product goal of an IT help desk? The product goal is like how can we get better as an IT help desk, really, right? That's the goal, you know, because it's like there's you know, taking calls, you know, getting tickets in and out. How do they get better at doing that is the goal.

SPEAKER_02 15:21

Not yeah, I think I I like that one too, JJ, because I have this issue too. We have a lot of teams that work on sustaining activities, you know, like like they work on product improvements that are minor, but that we that means they're working on like 20 of them at once. And they're always like, I can't have a product goal. And it's like, well, you know, I think that that's a great advice, which is you know, your product goal might just be how do we work faster or better together to deliver this variety of things that we deliver, like uh IT help desk or what have you, something that unifies the people on the team towards something, right?

SPEAKER_00 15:57

Yeah, and it's so like okay, how it one of the things, especially in sustainment kind of teams, is say take you know some percentage of your capacity and devote it to process improvement. You have a Kaizen, even though you don't. So, how do you get better together? And how do you inform each other and learn? Like one group we worked with a while back was a uh accounts payable group at a global corporation, and we put them three, and then these accounts payable, they just write checks all day, right? They got the reform, yeah. You know, you know, it's not not even they're not hiring anybody, they're not even you know deciding whether to buy it. They're the people who just write the checks when the form comes through. And they're like, How can we be a team? We just you know, there's like kind of a eight about kind of whatever it was. And uh what we said, let's just try it. And then again, that transparency is they realized, well, we can get better at this, and all of a sudden, every single one of them said, Oh, well, the people are feeling at the request form wrong for me, too, in the same place. Maybe our form is wrong. It's not just our people being, you know, we have to bounce back the request all the time. Maybe we should change the form. And they started getting better and learning together how to operate as a group that they also operated independently, not as a team. Yeah, they realized, well, no, it's all this. And then what one of the things that happened was uh they what one of their major headquarters is in New York when COVID happened, the uh CEO of the company said, you know what, I want to prioritize paying all the small vendors because they're the ones who can't wait six months to get paid.

SPEAKER_02 17:29

Right.

SPEAKER_00 17:29

And if we let them you know wait that long, they will go out of the business.

SPEAKER_02 17:33

Sure.

SPEAKER_00 17:33

Just prioritize that way. And the council paper said, No problem. That's just reordering the backlog.

SPEAKER_02 17:40

Yeah.

SPEAKER_00 17:40

And they said, if before having that transparency and knowing that working as a team, they couldn't have done that.

SPEAKER_02 17:47

Yeah, that's that's that's a good one. Um, because the the next question I think I have is around the idea that you know we want to have empower people, right? One of the challenges that I've seen in my industry is people sometimes use Scrum as a micromanagement technique, right? So they create a backlog of all these things, and then you know, either a team below them or some team down the chain just gets these things and has to do them. Right. So, how do you recommend structuring a backlog so that at each level in an organization, teams feel genuinely engaged in and therefore accountable to the long-term goals, strategies, objectives?

SPEAKER_00 18:31

And that can, you're right, that can get tricky, especially in a large organization, right? You're in a 30,000-person organization and you're on the IT desk in Peoria, and how does your thing you know mesh up with you know, global strategy in London or whatever? You know, it's like, how do you do that? And so the most important thing is you say, okay, here's the goal at whatever level of abstraction you want to get, whether it's the three-year goal, the year goal, the quarter, whatever it is, next week, uh, and say, here's what we here's what done is. We know we will have accomplished this when this is true. And like if you're building a race car like you used to do, it's like, well, the car drives. It wins race, it goes fast. But it's you know, but it could be what you know, whatever it is. We provided this service or we've helped these many people and say, okay, now that's what I want, people. And then at the next level, they'll say, okay, well, if in three years we want to have this kind of we want the world to be in this state based on our organization, all right. I and now I gotta figure out how I add up to that, and how what's my part in this? And the most important part is the discussion between senior leaders, the people below them, so there's a golden thread because often what happens, especially in a large organization, but it happens with the small ones either. You know, the senior leaders say, Well, I want this, and then the people go away and they don't do that at all. They think they're doing it, but there's not this conversation. And often it's because the seat more senior people don't get involved enough in forming what that definition of does.

SPEAKER_02 20:07

Right, right. They think empowering is we told you what we want. You guys can do anything you want, but if they have no guidance, they might come back with something completely different than what the leader is.

SPEAKER_00 20:16

Like customer was talking about this morning when I was talking about you know, uh the working with the Royal Navy, you know, the head of the Royal Navy shows up for these threat reviews. You know, he's he's he's a busy guy. Yeah, trust me. He's a really busy guy. But he shows up because he knows, and every senior leader should know this, the most powerful thing you have is your time of attention. Things you pay choose to pay attention to are the things that are gonna be most important to your organization. And if you say this thing is a priority for a strategic priority, you should show up and really engage in a feedback cycle with the people who are building that. Otherwise, they're not gonna they're not gonna make the right thing, and you're not gonna learn yourself as a senior leader. Oh, they've done this, I thought what we want to do is that, but actually it's gonna be a little because they've informed the senior leader and the senior leader has given them this two-way conversation. Yeah.

SPEAKER_01 21:10

Well, and I love that because that's so high level to be talking about the attention that the leader gives to something. Whereas often when we're thinking about people learning about product goals and they're worried about how do I write a product goal, where do I put it, which tool is best for me, right? Is it Asana, is it Jira, whatever? Where do I want to make it visible? Um, but that recommendation to think about where you're spending your time as a leader for the product goal, I think is more important than what sticky notes do you use, or what tool. If I'm interpreting what you said, all the tools are horrible.

SPEAKER_00 21:48

I've used I've used most of them as you have to. They all suck. But then nothing. Okay. I'm sorry?

SPEAKER_01 21:59

They could be better than. Nothing.

SPEAKER_00 22:03

Especially in a large organization needs some way of tracking it. It needs some way of doing it. But what you know, given that you absolutely have to have one, especially in an organization of any size. The thing you should really think about is that is to enable you to deduce this kind of thing and to choose what to pay attention to. And really it's a cost, right? Any system that you use has friction built into it. And it slows things down a little bit. And there's a cost to it. All right, fine. But what you want to realize is like, well, what is it trying, what why are we using what is it supposed to allow us to accomplish? And so what is the easiest way? And I'm a big believer in doing stuff uh physically with post-its and flip charts and all that kind of stuff, and then turning it into electronic stuff. So one of my teams they just have AI listen to their planning meetings, and then it draws up all the cherry tickets and builds the sprint. It's wild. And they're at a customer now where they're doing one of the first things we do is crumbling. We go to a large thing, we do an assessment. Like, where's where is the current state of the organization in terms of agility, ways of working, productivity, prioritization, all that kind of stuff. And in that we do like a survey and we do, like in this case, pretty big companies for like 50 interviews. And so they also had AI listen to every single interview. And it started saying, hey, I've noticed this pattern across the interviews. And now that I've been you know trained on the scrolling data and how you do this kind of stuff, this issue that these people create, you know what? In sprint six or seven that you're doing of this, that's when this is gonna come up. And it put something in the backlog they did not tell it to do, it just did it, and it was right. So AI is pretty interesting. And yeah, I'm getting blown by more and more by that. So, but that's one of the teams that scrumming because it's doing is just like, whoa, that's wild.

SPEAKER_01 23:56

Um maybe there's some hope for the tools that we all have in maybe there's some hope. I I think the problem I always have with sticky notes, and Eric can attest to this, my penmanship is terrible. So if I'm given a stack of sticky notes, I'm gonna have to explain it to folks and talk about it. But I think actually that's usually the point anyway, right? Like you can write it on a sticky note, but make sure you talk about it with other people. So that's it.

SPEAKER_00 24:21

What is what is the point of the sticky note? It's capturing an idea, it's capturing that the decision or the focus of a conversation or of an idea, you know, or hey, I'm putting this on sticky notes because I think better. Like some people just think better just to have things out of their head, right? Let's get the cognitive load of off of just trying to remember everything. You know, I know I have that. I panic. I'm like, oh, I gotta remember that, I gotta remember that, I gotta remember that. So but if I can write it down, all of a sudden I can say, well, I still might not get to it because I can be lazy, but at least I know and I don't have to worry about not doing it.

SPEAKER_02 24:56

What's the I have one kind of curiosity um because I I I work a lot with different teams and see a lot of mistakes made. Um what what would you say is the single biggest mistake that you've seen teams make when they try to use um backlog to manage their long-term priorities and goals?

SPEAKER_00 25:15

They don't prioritize.

SPEAKER_02 25:17

Ah, okay.

SPEAKER_00 25:18

They don't prioritize. They just make a list and they really don't know. They just make a list of stuff and then everything's of equal importance.

SPEAKER_02 25:24

Sure.

SPEAKER_00 25:24

And that's that's a big one. The other one is uh, as I said earlier, is having a really clear definition of done. A really clear what are we trying to do? How will we know when we're done? What does that mean? Because that can that can cost you in both ways. Sometimes you'll do more work uh than you should, than is valuable, sometimes you'll do less or you'll go the wrong direction. And it really helps again to have that conversation of you know, that backlog refinement of like, what does this mean? Because that way we all agree. Because how many times you've must have had this all the time, Eric. Everyone says, Oh, we understand what this epic is about or this story, and but there's nothing, and then they just go, Well, that's not what I meant.

SPEAKER_02 26:05

Yeah, it's like, well, why did you or they get or they get all the way to what they think is the end of it, or you know, whatever, and they're like, hmm, is this really done? What is what is done, you know, or or they just drag it out forever. That's what I see more often is just this thing's supposed to be done in three months, and then somehow it just morphs into something completely different because they didn't clearly state the increment ends here.

SPEAKER_00 26:30

Yeah, yeah. Like this it's the deadline, right?

SPEAKER_02 26:34

Right. Yep.

SPEAKER_01 26:36

We've even learned things like this in building our own podcast. Put two agileists into a room that have their own ways of doing things, and you learn some things.

SPEAKER_00 26:45

Yep, definitely. Yeah, definitely. It's a lot of communication. Yeah.

SPEAKER_01 26:50

Yeah. Front and center on that one. And so, you know, JG, we love to give like specific challenges and calls to action to our listeners. Things that like, if they listen to the episode, they're like, I want to try something. So if somebody's thinking whether they're, I don't know, maybe you're gonna have to give two different calls for action if you're up for it, because some people are gonna listen and they're like, I don't have a product goal. There's gonna be other people who are like, I have a product goal. What would be like the one thing that you'd encourage someone who has a product goal? What would be something you'd ask them to consider as a way to improve their approach to product goals? You know nothing about their tools, you know nothing about their industry, but you know they have a product goal. What would you say is a pretty general piece of I would say it's just what Eric said.

SPEAKER_00 27:38

Know what done means. And does everyone agree? And then write it down. And so, and that will speed you up so much. Because I was talking about that one team that didn't have the team together and the product goal, and all of a sudden they really only had two sprints at the end of the day to do it. And they figured it out, but know what done means, and how will you know what you know if it uses the terms like what are the acceptance criteria? What does done mean? How will you know that you've changed the world the way you want to change the world? How will you know that whether that is how that's really good advice?

SPEAKER_02 28:13

Yeah.

SPEAKER_01 28:13

Well, and having listened to you give that piece of advice for somebody who has a product goal, is your advice the same for a team that doesn't have a product goal? I'm like, you're like Ditto, same?

SPEAKER_00 28:23

Yeah, like it's absolutely the same. Like, well, why do you exist? Yeah, not you know, ex you know, existentially, but you know, like like okay, you're a team, you're trying to do something. Why? Um, it's the same thing as as we were just saying, have a product goal. What is the value you're delivering to the world? What is the service you're providing? Why is a company paying you money? Why are you, if you're, I don't know, volunteering at your church, what are you trying to accomplish with that, you know, whatever the church sale or whatever? What is it that you're trying to do and sort of capture it? And then you when you're working on a team, which is what agility is about, just make sure everyone shares the same view of what that is.

SPEAKER_02 29:03

Sure.

SPEAKER_00 29:04

What are we trying to maximize? What are we trying to change? What are we trying to deliver? And we all agree that we'll know, we'll done it when this happens.

SPEAKER_02 29:14

Sure.

SPEAKER_00 29:15

When this is true.

SPEAKER_02 29:17

That's powerful. That's really good.

SPEAKER_01 29:18

All right, everybody. So you need to have clarity. Where are you headed? What's your definition of done? Have shared understanding and agreement on what that is. Right. There we go. That was my paraphrase of JJ. I shouldn't have tried to do that. But we are so grateful for you being here. And I think if people want to learn more about your work, the case studies that Scrum Inc has available, uh, they go to your website.

SPEAKER_00 29:39

Yeah, just go to Scrum Inc.com or you know, pick up either of the books, uh, The Art of Doing Twice the Work in Half the Time, or the Scrum Field Guide. You know, and sometimes I just say books. Want to know how to do it? I actually wrote down exactly how I do it. Yeah.

SPEAKER_01 29:53

Yep, they're both on our bookshelves for sure all the time. You can find them on all the online platforms. And uh yeah, check out your local bookstores too. And so, JG, we are so grateful that you spent some time with us as a co-pilot here at Agile Driven Impact. And uh I think, yeah, given some great tips for folks to consider. And we need to just give one little shout out, if we could, to our season two sponsor while you're still here.

SPEAKER_02 30:19

Absolutely. Yeah, Agile and Nonprofits. So they also have great resources for your mission-driven organization, um, templates for things like backlog, story mapping, other things like that. So check them out at agile nonprofits.com.

SPEAKER_01 30:33

Yep.

SPEAKER_00 30:34

Yeah, it's a great resource. Yeah, definitely.

SPEAKER_01 30:36

Well, JJ, thanks again for being with us. And uh, our usual sign off line is keep driving that impact. So if you don't mind, we'll use that as our closer with you too, right? Sure. All right. So thanks again for being with us, and everybody will see you next time.

SPEAKER_02 30:50

Thank you, JJ.