Sprint Goals with Maarten Dalmijn

Join Murray Robinson as he chats with Maarten Dalmijn about Sprint Goals. We discuss how sprint goals should act as a primary mission for a sprint, around which everyone’s tasks should revolve, rather than focusing on individual deliverables. We talk about challenges to implementing this approach, the importance of measuring outcomes over output, and the need for competency and trust in the team. This conversation highlights the importance open dialogue with stakeholders, and the necessity of adaptability in the face of uncertainty.

Read along you will

Welcome to the No Nonsense Agile Podcast. I’m Murray Robinson. 

Maarten: I’m Maarten Dalmijn. 

Murray: Hi, Martin, Thanks for coming on today. 

Maarten: Super excited to be here. 

Murray: Martin, I wanted to talk to you about your new book on driving value with sprint goals. 

We’ve had you on before, but for people who haven’t listened to that episode, can you tell us a bit about yourself and your background and experience? 

Maarten: Hi, I’m Maarten Domijn. I started working for myself around one year ago. I’m now advising companies, startups, scale ups . So I studied biology. My first job was in marketing. Then 2008, the crisis hit and I started working as a QA because , even with no background in it, I could get a job back then. And , I taught myself how to script. I became a business analyst, scrum master, and , the last five years working in products. Ultimately as a head of product and, that’s my career history in a nutshell. And I worked at scale up startups and corporate. So all kinds of companies.

Murray: Good. maybe you could tell us a little bit about your new book, Driving Value with Sprint Goals 

Maarten: So the book is about sprint goals. 

It’s basically about how do you build empowered teams that drive delivery value. So even though the title contains Sprint goals. A lot of the ideas behind it work in all kinds of empowered teams. It doesn’t really require Scrum to work.

Murray: Okay, so who did you write it for? 

Maarten: I actually tried to write it both for experts and for laymen. I want it to be easy enough that someone who didn’t have expertise, that they would be like, Oh yeah, I get it. I understand why Sprint goals are important. And that maybe experts would look at Scrum and Agile in a different way. We’re like, Hey, I didn’t look with this Sprint goal angle at Scrum before. And as well the book. Contains many easy concepts which you can use to influence the C level. If someone in the C level would read it, they would understand, okay, this is why they make a roadmap and stuff doesn’t get delivered on time . 

Murray: I wanted to ask you… Why you wrote it 

Maarten: I think there are two reasons. The first reason is teams are not delivering value. And I think the reason why many teams are not delivering value is tied to how they do planning. And because if you make , overconfident plans, you make plans for a year or whatever, then there’s a good chance that you’re running a feature factory and you cannot discover and learn because the way you do planning prevents all of that.

Murray: When I started doing Scrum back in 2004, there was no sprint goal. And I don’t think there was even a product owner back then.

Maarten: The first version, there was no product owner, as far as I know, .

Murray: But I see that they introduced sprint goals in 2013. And what’s interesting about that is I have never seen anybody use sprint goals. So I wonder how common it is. 

Maarten: Eight years back, nobody was talking about Sprint Goals. And I think now the conversation is starting and there are more teams using it, but I still think there are more teams not using it than are using it. 

Murray: Why do you think the Scrum people introduced the idea of goals? 

Maarten: So scrum is intended for complex work. You had Stephen Bungay in the podcast. So he talked about friction. So the more friction the more wrong your predictions and plans are going to be and the actions that people do they might do incorrectly. And even if they do everything as intended, you’re not going to have the results you’re expected because there’s just a lot of friction, a lot of surprises. I believe that when you’re doing complex work, because you have a lot of surprises you need to be able to adjust the plans to produce the desired results.

And there are two ways of doing this. Way one is you go to someone else and ask, Hey, what should I do now? Or you provide sufficient context and intent to tell them, Hey, you can change the plans themselves. And I think that’s a way better way of doing things than always constantly asking, what should I do?

Marquette in his book, Turn the Ship Round put it really beautifully. You want to move authority to information, or information to authority and basically the teams, the people that do the work have all the information. So how do you empower them to act based on information? And that’s where Sprint Goals come in.

Murray: Okay. 

So presumably you have an organization goal and then you have a product goal. And then you break that down into sprint goals. 

Maarten: Yes. 

Murray: So maybe we should start with 

product goal. What makes a good product goal?

Maarten: So in the book I introduced an acronym, which is called a focus. So I think one of the most important things that should allow to focus, because if you have 10 things you’re working on, then it’s very difficult to work as a team because you’re going to be pulled in all different kinds of directions. It should be. F, so fun, the O is for outcome oriented. So what are we looking to achieve. C is for collaborative, like it’s something that’s created together. U stands for ultimate. 

So why are we doing this? What is the relevant context? And then the S stands for singular, like one thing, not two or three or five things that you see. So I think that’s a very handy acronym and you’re talking about the product goal. So for me, a sprint goal and the product goal, they’re the same thing as the difference between a product backlog item and an Epic, like a product goal is too big to work on, so you need to break it down in smaller chunks. But they exhibit the same properties. So focus applies equally to sprint goals as to product goals.

Murray: So should a product goal be, at a different horizon? So like 12 months or 

something like that. 

Maarten: I think that also depends on the stage that your product is in. If you look at the scrum guide, they say there should be one product goal. I don’t think that’s entirely accurate in that sense because you’re always working on multiple things at the same time.

You care about retention, but you also care about acquisition. If you’re working, for example, late life cycle project, we’re doing all these small improvements. You’re probably not going to have a very large time horizon, 

But if you’re working on a, maybe an early stage product, then you’re already thinking very far ahead where you want to go. So I think it really depends as well on context. But generally, yes, it should be, three to six months maybe 12, but not longer because every day you learn, hopefully.

Murray: We did talk to Pavel Huryn about product roadmaps and product roadmaps and normally a list of large features with dates. And instead of doing that, what we should do is a series of goals. So you’ve got 

your big product goal and then your roadmap is this goal next, and then that goal, and then the other goal. 

Maarten: Yes. I think that makes a lot of sense because. As I also talk about in the book, you should do humble planning, which is basically, you should not make all these plans for one year , because every step you take, you learn something new. And that means you can make your plans better, but that means you should have plans that allow for that. And companies, they have these roadmap of one year where all steps have been thought out, then there’s no room for this discovery and incorporating these learnings. So yes, I absolutely agree with Pavel by focusing on the goals. That means you can discover, you can learn stuff and that the plan can emerge as you do the work, which is necessary if you do complex work .

Murray: All right. So we’ve got our product goal. We’re going to focus on for the next couple of months. And then we’re going to break this down into a series of sprint goals, do we work out what each sprint goal is going to be for the next four or five sprints, or we just do the next one ahead?

Maarten: I don’t plan sprint goals ahead. You do have a picture of upcoming stuff that you’re doing, but every sprint, you just take a look like, what did we do last sprint, what is a sensible next step? And, but you really start with the sprint goal. You don’t start with all the product backlog items

Murray: Can you give me an example of a sprint goal? 

Maarten: So I worked at an e commerce company and we were rebuilding our platform. And one of the biggest challenges we had is that we had all these third party systems where nobody knew how they worked. So if you’re working in e commerce you have to send an order to the warehouse. It needs to go to finance. It needs to be paid all these different systems and nobody knew how they worked. So we actually set a sprint goal where we actually said, why don’t we make it possible to place an order? We get it shipped to the office, then we return it, return gets processed, we get the refund, and then we make sure that the money is transferred to the bank account, so that it’s really there. So this is really an example of eliminating risk and uncertainty. 

But actually… everybody loved it and they were making fun hey, maybe let’s order a red dress and if it’s on time and the refund’s on time, then one of the developers, Donnie, was going to wear it and everybody was excited. And in the end, what happened is within two weeks we got it working and we actually shipped an order. It was returned. It was refunded and everybody was super happy. And then it was more question of, okay, so now we have all these other countries and all these other payment methods, but it really made everything so much easier. So this is, I think, a good example of a Sprint goal.

Murray: Why does it make it easier? 

Maarten: So basically there was a lot of uncertainty and if you don’t know all the stuff you have to do, then it’s very difficult to plan the work or talk about it because you just don’t know. You simply don’t know. And this was an example of, we had a lot of fog and we thought about, okay, what is the best step we can take so that we get a clearer picture of what’s going on. Then that makes everything afterwards easier because you just know how it works. There’s still some uncertainty, but it’s not like as uncertain as before.

Murray: Goal of getting your returns working properly on an e commerce system. That could be quite difficult. I know people who’ve 

taken 

a long time to get that working. 

Maarten: Yep. 

Murray: It sounds like it could have been quite an optimistic goal. 

So how do you know that your goal is something you can achieve in a sprint? 

Maarten: You don’t necessarily. And I think that’s also not a bad thing. So this scenario, we had an old platform, so we knew how it worked. So that means. You can get it to work. It might be really difficult, but there is something that works. So you should be able to get something to work. But I’ve also had situations where we don’t know if we’re going to make it. Maybe there’s some kind of obstacle. We cannot do it. And I haven’t had the situation where we didn’t find a way to work it. But I have been in situations where we discovered, hey, we cannot make it in two weeks. Then you just make as much progress as you can. That’s how I see it. Ideally you of course achieve it, but if you discover you can’t you make the most progress you can.

Murray: so let’s say you’re the product owner and you’ve got an idea for the goal you talked about at getting your refunds returns working. How do you do that with the team? You go to the team and go, okay, team, this is our goal. Tell me what stories you’re going to do to achieve this goal, this sprint. Is that that how you do it? 

Maarten: No. it Should be really collaborative. So at the sprint review we already would have shown Hey, this is the goal we’re heading towards. It might be a little bit bigger or a little bit smaller, but this is what we’re thinking. So I, we would sit together and then we just think about what makes the most sense. And yes very often I did take the lead in those discussions where I said, Hey, like in this case, I thought about what can we do to really make the whole project easier, . And I just pitched this idea. If we have two weeks? What if we just try to do this? Because everybody’s talking about refunds and how returns work and nobody knows it. Why don’t we just try to do it? And then they said, but we don’t know. We’re not going to make it. blah blah blah. I said, okay, I’m fine with not making it. I’m absolutely fine with not making it. As long as we did the best we could, I’m a happy man. And if we try to learn as much as possible, because we really have no clue how this works. One of the obstacles, during the sprint was the legacy system.

There are many fields that nobody knew how they worked. And the developers came to me and said, we want to remove them because why maintain the same thing? And I told them, look, first, just let’s just add them in. And then we can ultimately always remove them. But we have two weeks, so we added the fields. They first tried removing them and then it didn’t work, of course, because they didn’t know. So this is the discussion. 

Murray: I think the normal way people would do it is that they would say, We don’t know how to do this. We don’t know how to estimate it. So we’ve got to do some planning. So we’ll put some, architecture and requirements spikes in our backlog and we’ll get our BA and architect in our team to go and investigate it and write it up and do some architecture design. So basically we’ll do analysis and design for two, four, six weeks . Then we’ll have some certainty about what we’re going to do and how big it is and whether we can do it or not. Do you see that happening much?

Maarten: I see it happening a lot. 

And I think it’s a really big problem. I can give you a concrete example. I once joined a new team and we had to do something where we absolutely knew nothing about. 

We had an experienced scrum master and he said let’s, do sprint zero, let’s make all the requirements and six weeks, doing a lot of upfront. And I told them like, look, we’re going to do a spike, a proof of concept because we know the most valuable thing it’s this what’s going to happen. We’re going to do this either after the spike, we find out we can’t do it. Or we find out we can do it even maybe within the sprint, or we find out all the stuff that we didn’t know.

And now we know, and then we can gradually start working on it. Actually what happened in this case is we finished it in two weeks. We had something working in two weeks. So I think, this is a good example of sometimes you need to get your hands dirty. Like you cannot remove all the fog by thinking you need to do stuff.

And I think a lot of the balance, is on thinking and analyzing, but if you’re surrounded by all of this fog, then all this overanalyzing and thinking introduces even more fog because you’re going to make assumptions over what’s behind the fog and you just make things worse.

Murray: I’ve tried to persuade people to do that before, but we often get a lot of pushback from architects saying no, you can’t do that. It has to go through the architecture review board and this architect, who’s not even in your team has to do 

it. And IT managers and other managers who say no, you can’t do that until you’ve done the requirements and had it approved. There’s this real fear of, just doing it. Everybody wants all this certainty before they start. Yeah, 

Maarten: absolutely true. 

I was always a product owner. So I think it’s really important. I always said, look, the worst that can happen is we don’t make it. And if somebody is going to get angry, they’ll come to me and I’ll take the blame. So don’t worry, but you’re right. In the case of the architects, I think those are very fundamental discussions that you need to have, because I firmly believe that the best architectures gradually emerge. I don’t believe that you plan them all out with all the details. I’ve seen it with rebuilds. If you try to build a complex system to replace a complex system you just introduce new problems that are different than the ones you had before.

Murray: The… argument against this approach, , is that you’re making incremental changes when you should be making fundamental changes. And you’re never going to get to the… fundamental change by making a whole series of incremental changes, because the optimization landscape where you have a series 

of Hills, and you’re on a small hill, and if you incrementally improve, you can get to the top of that small hill, but you’re never going to get to the top of the big hill next door by doing that.

Maarten: So basically it’s about polishing something you have versus doing something radically different. There’s some truth to it, but I think the other side of the coin is you’re going to go for something fundamentally different, which actually is not necessary, which is what I see because we imagine, something we need, but we actually don’t need it.

So in my experience, complex systems, they start with simple systems that work and they emerged over time. And of course you have technical depth and all these things, but I think the worst systems are actually the systems that start out as complex. And that’s what we tend to do because we just believe we know all the problems of the previous system so that we can predict. And then , systems behave as they ever will on its own. 

And that, part is the scary part. If you go for the fundamental thing. 

Murray: What I see a lot is we have this complex system, which we built over a long period of time, and it works and does what we want and everybody likes it, but it’s falling down and goes down every night because we haven’t invested in it.

Maarten: Correct. 

Murray: We have one guy who works on it and now underlying platform software is 10 years out of date. So we’re going to move to something new, which is radically different from a completely different company. And so basically we’re going to have to build it all again. That’s what I hear a lot. And in order to do that, we have to spend 12 months doing our architecture first. And it’s Agile, so we’ll do it in sprints. 

Maarten: I see a lot of rebuilds taking way longer than expected. And then when it’s done, it’s actually not the best result. There’s some stuff that’s better, but it’s definitely also a lot of things that are worse.

Murray: The common thing I see is that we’re going to rebuild what we’ve already got on a new platform, and it’s going to cost a lot of money. Like many millions of dollars, and it’s going to take quite a long time. By the time we finish, it’s late by years sometimes. And it costs twice as much as we expected, sometimes more, and it does less than what we had when we started. But now it’s on Oracle or SAP or something. And since we’ve spent all of our money, we’re going to go back to having one person look after it

Maarten: And then 10 years later, somebody says this doesn’t work and we need to rebuild it again.

Murray: Exactly. That’s unfortunately common. So anyway, let’s go back to goals. Cause I do like the goal approach much better. It’s very much the same as we were discussing with Mission Command, although we’re looking at a much lower level now. Although people have told me that the way NATO is working and the US is using Mission Command now, they have been driving it more and more down to the lower level. 

Do you want to describe Mission Command? Because you talk about it in the book. 

Maarten: It’s called as well, Auftragstaktiek, so it’s basically where you give the people that do the work a mission. You tell them, this is what we’re trying to achieve. This is why it matters. You go figure out the plan and when you’ve made the plan and you execute the plan and you need to change the plan, you can act in spirit of the intent of the mission and you can make changes, any changes you want. And because that’s the reality, like on the battlefield circumstances change, you need to inspect and adapt. And because they understand the mission, they can make any changes necessary during the course of battle without waiting for others. The point is to make decisions as quickly as possible without depending or waiting on the information.

Murray: So the goal stays the same but the way we’re going to achieve the goal changes because we’re discovering new information as we go.

Maarten: yes, exactly. 

Murray: Yeah, Makes so much sense. All right. So we’re down at the sprint goal. We’ve got an overarching product goal for the next couple of months we’re focusing on, and we’re collaborating with the team to come up with a sprint goal for the sprint in planning. So presumably. What’s happening here is that the team are negotiating with the product owner about what’s an achievable goal for the sprint. Is that correct?

Maarten: I think it’s back and forth. 

Murray: Yep. And then they’re saying, okay, we’ve got all of these features or user stories. Which ones should we do to achieve the goal? Is that how you would develop the sprint backlog? 

Maarten: Ideally, if you have a good goal, then they can just pull in the work, they can refine it together. Of course you’re still present but they won’t need to ask. 

Murray: So you don’t need a sprint backlog full of user stories 

Maarten: Not necessarily, ideally, yes, there is some but both work. I don’t think the matter, the moment when you do refinement really matters. The problem is if you do it very late, like during sprint planning and you have dependencies on other teams, that’s when you get problems or you need some kind of UX design and then can they do it within the same sprint or, so it can introduce problems.

Murray: I like this approach. It’s much more flexible and much more fluid than the usual approach. Effectively what teams do is that they create a contract at the beginning of, the sprint between them and the product owner saying, we’re going to deliver these 10 features. And then they don’t. 

Maarten: No. And you know why they don’t Murray? Because The estimates are wrong. , those 10 user stories, you estimate them as, I don’t know, 30 story points, but they’re actually 40 story points because one of them is just, twice as difficult. You shouldn’t be planning based on 100 percent of your capacity, because that means there’s no room for emergence, for learning, for discovery. You should always plan much lower, because as you know, right, 70 percent resource utilization, the waiting time shoots up.

And then this way, let’s say you need help from another team because they’re also working with sprint goals, then there is at least immediately room to help and when you discover something unexpected, you just resolve it. But the moment you’ve committed to these 10 things, which are actually already overcapacity, then you’re immediately have a traffic jam and you’re immediately screwed and that’s what a lot of scrum teams do.

Murray: What I see a lot of is, Last sprint, we planned to do 80 points and we did 30 points. So therefore this sprint, we’ve got to do those 50 points plus another 30 points cause we’re behind and we promised the product owner and he promised or she promised the customer. It’s very common to see teams that massively over commit every sprint. What do you say to them?

Maarten: As a product owner, I never discussed Velocity. I don’t really care about Velocity. And I think it’s much more interesting to set a goal with limited capacity. do use the Velocity together with the team to provide forecasts, but nobody has to know the Velocity. It’s none of their business, but you just tell them, Hey, we’re working on this. And based on the current information, we expect it to be done, in six weeks. That’s it. Why should we be talking about velocity? I don’t see the point to be honest, because then you get all these kinds of conversations. Why is your velocity lower? Blah, blah, blah, blah. If you’re talking about, Hey, it’s going to take six weeks and then you update that the forecast as you discover it takes longer, then you don’t have this stupid velocity pressure, which is actually results in a lower velocity in the end.

Murray: All makes a lot of sense. I think, though, that it relies on quite a lot of trust and quite a lot of capability in your team. What I see quite a lot is that you have a team that’s made up Of some of your own people and a bunch of people from a offshore service provider. And if you don’t tell them exactly what to do they won’t do anything at all. They’ll just be totally unproductive. You can’t trust them. So you’ve got to have a very detailed plan with very detailed user stories and definitions of ready, and you’ve got to give it to them. And you’ve got to be checking every day to see if they’re actually working on it or if they’re working on some other customers project. 

Maarten: I do think that’s fair. Imagine you’re in a situation where you’re working with an offshore team, they’re inexperienced. They’re going to need more handholding. They’re going to need more spoon feeding. But then the question is, can you change that over time? And I believe you can, but it probably will never be the same as your own in house team. You also have to work with what you have. And what I can say is from having worked with some offshore teams is that, if they struggle to make decisions or they don’t have the context, you need to do more spoon feeding. It’s possible to fix, but that means you need to invest in a lot of effort for them to understand the domain, get them close to the teams. And very often that doesn’t happen. And then you’re stuck with the spoon feeding.

Murray: We talked a while back to Eric Lopez, who is a retired US army colonel, . Who taught people mission command. And he said that the US army realized after they’ve been doing this for a while, that they had to introduce competency as a very important aspect of working in a goals based way. If they are skilled and competent, then we should empower them and trust them and use mission command and goals based approaches. But we have to recognize that if people are new or inexperienced then that doesn’t work, 

Maarten: Yeah, I absolutely agree with that because in the end it’s about taking ownership. You have to be able to take ownership and if you don’t know what you’re doing, you can’t take ownership over it. Let me give you an example. I’m not that good at do it yourself. So basically I can watch a video online but then the problem is there’s always something which is a bit different, and then you’re stuck immediately because you’re like, Oh, what do I do now that the script doesn’t work? If you’re really good as a do it yourselfer, you’ll immediately realize all the different options, what you can do in the moment. If you’re like me, you’re not good. And you immediately start swearing and what do I do now? I don’t know. 

Murray: let’s go through how you use the goal for a sprint. So we’ve talked about planning. We’re going to agree on a goal together with the product owner having a lot of influence on it because they’re talking to stakeholders and customers but everyone can participate. And then we agree on what we think is a realistic goal together. And then we’re not too worried about developing a fully fleshed out sprint backlog but maybe we’ll put down what we think it is. We’re not too worried about developing definition of ready. I think I saw that in your book.

Maarten: No, absolutely not. We’re not worried about it at all. 

Murray: So we’re going to go back to the idea of a user story is a conversation starter. That’s 

Maarten: Yeah. 

Murray: So we’re not going to write two pages of acceptance criteria and our definition of ready before we start. So then the team is just going to self organize and work out how to achieve it. What they’re going to do first. So then each day in the standup, how do we, how does the goal come into play at the standup or daily Scrum as it’s called now? 

Maarten: So basically every daily scrum, you also set like a goal for the next 24 hours. Hey, what we’re going to achieve in the next 24 hours. And you reflect on that. But the key thing . That should always be the center is, Hey this is our goal. How’s it going with the progress? Do we still think we’re able to achieve it? I also want to stress the reality is there will always be stuff unrelated to the sprint goal in the sprint. So please also discuss that. But I do think the most important thing, the first thing we should discuss is the sprint goal, because that’s basically where we said this is our mission for the sprint. So that’s the key thing that we should inspect. I think that helps a lot with focusing the conversations because you’re really focused on this is the most important thing. And if people need help to achieve it, then you were going to focus on that.

Murray: So what are we going to do today to help us achieve the goal?

Maarten: Yes. 

Murray: Not, what are you working on? What did you do yesterday? What are you going to do today? And what blockers do you have? So we’re not going to do that.

Maarten: No I wouldn’t do that.

Murray: I like it. So radical. We’ve just been talking to Joe Justice about how things work at Tesla, and this is basically how it works. It’s outcome based. But the thing he said is that they have measures for everything. If you’re in the paint shop, they have a measure up on screens around the paint shop. How many cars are going through, what the quality of paint was. What the current customer feedback rating is. So they’re really focusing on measuring. 

Let’s say we’ve, come to the end, we’re doing our review. What do we say when we’re talking to our stakeholders about our goal. How do they know that we’ve made progress on our goal or that we’ve achieved it or not? 

Maarten: So at the Sprint Review, you should really talk about what was our goal that we believe we’ve achieved it or not. But one of the main things which many teams do wrong is because it’s an outcome based goal, the results are often going to be lagging. There are many teams when something is done, it might not even be deployed already. So there isn’t even any data yet. But let’s say you’re one of the lucky ones. So you’ve achieved a sprint goal. It’s already deployed. You’re already collecting data. So you should revisit those goals like this is what we’re expecting. This is how we did. And then you can learn from it. You can inspect and adapt. And this is radically different than what you see in most scrum teams where it’s okay, the sprint review is for demoing the stuff we’ve delivered so that they know we worked and then next sprint we’re going to demo new stuff. And then the stuff they delivered in past sprint never gets revisited. It’s because it’s already been delivered. I think that’s the crucial difference.

Murray: This is also a lot like we talked about with Tom Gilb. He goes into big organizations and he says, what’s your goal? And , they spend a lot of time working on that with stakeholders. And then, okay, what’s your team? What can we do this week to move towards that goal. And then after he gets the team together, he says, what’s the best thing we can do today to achieve our goal? And he just does that every day. He claims that it’s miraculously fast. Sometimes their goal is not features at all. It’s architecture or investigations. It doesn’t really have to be something that moves the customer metric.

Maarten: I agree with that. It depends on how much fog you’re surrounded with. Because if you don’t even know many things, how can you focus on results?

Murray: All right. So then when we’re having the retro, how does the goal come into play there? 

Maarten: During the sprint, you’re trying to deliver a product increments that meets the sprint goal and meets the definition of done. So then you inspect the way of working to see Hey, how good were we achieving that goal? What can we do better next time? And it takes the center stage because that’s the main thing. That’s the main purpose of the sprint. So you’re not going to talk about all the individual backlog items first. No, you’re going to talk about, 

Hey, how did it go with regards to the sprint goal? So the sprint goal is intertwined with every scrum event, in my opinion and that’s why it should take this center stage, because it means that we can look ourselves in the mirror, and say we did a good job achieving the results or not, instead of saying, Hey, we ticked off these 10 features in the sprint that we completed. It allows us to be honest because we’re focusing on the outcomes, not just the stuff we did, the outputs.

Murray: I’m wondering if the first thing we should do after we’ve defined the goal is to work out how to measure it. Then, make that a key thing in our sprint that we’re going to come up with some measurements. 

Maarten: I think that’s a very good point. That’s so outcome oriented. But then you first need to know the outcomes. In the book, I talk about the Northstar framework, which is a very simple approach where you can actually see which outputs. Drive certain outcomes. How are they connected? 

That can be really helpful. 

Murray: Can you talk us through your Northstar example that you used?

Maarten: Sure. I think it was time spent listening to music or on YouTube or watching videos. 

Murray: Engagement, was it? 

Maarten: yeah. And so basically the idea is the following, when you have a product, you always have two things. Value creation, which is you’re creating value for someone, but as well, you want to get money back in 

return, which is the value capture.

So 

if you look at YouTube, imagine you Murray, you’re watching a video on YouTube and you’re watching many hours watching videos, then you’re getting value out of it, because you’re enjoying it. But on the other hand, they are serving you ads. So they’re also making money out of you watching. And that’s why time spent watching a video is a good North Star is because it represents both customer value and both business value.

So both value creation and value capture, because you need both sides of the coin. Of course, that’s not enough. There are all these ways you can influence it. For example, let’s say you want to bring users back more often. You could send notifications. Or you want people to stay longer. So you can give them better recommendations.

Tailored recommendations. That means that you will watch longer. You just, you don’t have just a Northstar. You also have all these inputs, this constellation of metrics that influence this Northstar. And the idea is basically that Northstar is a proxy for value. So ultimately you care about money and revenue, but you cannot influence that directly.

So if you influence all these things on the left hand side, like for example, better recommendations, you can influence time spent watching a video. And that means ultimately more money. And that’s why I’ve Northstar is a 

very powerful tool because you make a working model for how your 

product delivers value and that you can evolve over time as you discover 

and learn.

Murray: I remember working on a multi million dollar e commerce project, which was designed to increase revenue, sales revenue, by increasing leads. And they had no way to identify which revenue came from their website. And they hadn’t put that on their feature list.

Maarten: Oh. 

Murray: So later on, when we delivered this project and we said, look, it’s, we’ve delivered all of these leads. It’s resulted in this revenue, different parts of the business said, no, we did that, the marketing team said, no, that’s because of our advertising and that on TV. And the customer service team said, no, it’s because of our sales incentive 

program. 

Maarten: Everybody took credits. 

Murray: Everybody took credit and nobody knew what it was from because they hadn’t prioritized measuring it. So it strikes me 

to come back to what I was saying earlier, that if your North Star metric is time spent watching videos. And that’s going to be your product goal. And you don’t have a measure of time spent watching videos.

Maybe that should be your first spring goal.

Maarten: No, you’re absolutely right. If you cannot measure it then you’re painting 

cars without having any clue how many cars pass through. 

Murray: Or what color you’re using or whether anybody likes it. And I think the reason people don’t measure it is because we are still in this paradigm of IT teams that build things for product teams who are in a different. Group, and and the IT teams are 

not going to try and build outcome measures because that’s not their job.

And the product managers often don’t build outcome measures because they’re just doing what the senior executives told them to do.

So they’re running a feature factory. So nobody’s focused on outcomes because all they’re focused on is delivery.

Maarten: You’re right. I think the crucial thing is how you do planning and roadmapping. If you tell all the teams, Hey, these are the features you’re going to deliver in the next year. And you hold them accountable for that, then nobody’s going to care about the outcomes because all they will be thinking is my team has committed to deliver this in six months. And if I don’t deliver it, someone’s going to be angry at me. I might not get a raise. And that’s what you see at many companies because timelines are easy to measure, whether a feature has been completed is easy to measure, but it rewards all the wrong behaviors when it comes to does it, this is really going to make a difference for our customers in the business.

Murray: All right. So using this example, you’ve got in your book, our goal is to increase time spent watching videos. Our hypothesis is if we bring users back more frequently, they’ll watch more. And we believe that better recommendations will bring people back more often to watch more things. So we better have a measure, but then let’s say we do have the measures of better recommendations.

We’re still left with a whole lot of ideas on how to improve that, that we actually don’t know whether they’re going to work or not. So how do we prioritize amongst those different ideas? How do we know which idea to do. 

Maarten: So this is a part in the book I didn’t really cover extensively, but if you have all these ideas, you should do discovery, you should be talking to users, you should be making small prototypes, this is a whole world on its own, but basically what it boils down to is. Building stuff is slow and expensive, so you should only do that when you have a lot of evidence that it’s going to work. And if you don’t have a lot of evidence, you should do cheap things to gather more understanding and learn stuff. And I think the main mistake companies make is that they have a list of a hundred ideas and they have to feel like we have to. Select all these ideas. But I think the main thing is start with that one or two ideas and do some discovery and learn from that. .

Murray: Could you talk about The two different versions of Scrum, the Anaconda, versus the Hummingbird type of Scrum.. 

Maarten: So Anaconda can eat like a goat and then they can, for a few weeks, they don’t have to eat anything. They just can rest, they can digest, life is great and that’s what a lot of Scrum teams do. They have 10 tickets at the beginning of the sprint and the goal is to. Complete those 10 tickets by the end of the sprints. So it’s really like the anaconda, like they start with a goat, they want to digest the goat, and when the goat is digested, life is great. 

The alternative is hummingbird. A hummingbird actually zips from flower to flower every few minutes, sipping some nectar if they wouldn’t eat for a few days, they would die so they, need to keep going and . If you do Anaconda style scrum, you make the plan from the start. Changes are bad. And when you do Hummingbird scrum, the idea is you start with a sprint goal and every day you pull in the work as is necessary and you make changes as necessary. So you can really act in the moment. For dealing with surprises as is the case with complex work. Hummingbird style scrum is way more flexible and will work far better. 

Murray: Okay. Let’s talk about overcoming some of the common obstacles to working with sprint goals

Maarten: I think there are many obstacles. let’s say. You are unable to set a single sprint goal, which is what very often happens. That’s usually a symptom of other dysfunctions. So it could be that the product owner is not that great at stakeholder management and they say yes to many things.

It could be that there is not really a strong vision or a good product. Usually it’s a symptom of other things. Another example could be component teams. If you’ve got a component team and you’re serving five other teams, it’s very difficult to have a single sprint goal. 

Another example is a huge product backlog. If you have a huge product backlog, then the goal is to deliver everything in the product backlog. And then it also becomes very feature focused. Maybe you also have some examples from your experience, Murray.

Murray: I’ve never seen anybody work with Sprint Goals. And the reason is because they are a delivery factory. The decisions are being made by senior management outside their control. So one senior manager asks another senior manager, can you do this for me by this date? And they say, yes. And then it just gets pushed down to the team to do, whether it could be done or not. So that would be a major obstacle that everybody’s disempowered. The product owner, product manager disempowered, and so is the team.

Maarten: I think the, biggest obstacle is planning. That’s usually the biggest one.

Murray: There’s this desire for certainty. There’s this really strong belief that if you’re any good. you will be able to do things with certainty. You’ll be able to develop an accurate plan and meet it. If you’re saying, No, that’s not how the world works. People are just gonna… Say, you’re rubbish. 

Maarten: I once gave a presentation in London with hundreds of PMs and I asked, whoever delivered everything on the roadmap on time. No one raised their hand. No. And then I asked who has gotten close and there were like a few people. And I said, Oh, you got very lucky. 

Murray: I don’t think I’ve ever seen a software development project deliver the scope defined in the business case on time and on budget, just because there’s way too many uncertainties. But it can be quite difficult getting through to stakeholders.

How do you work with stakeholders to persuade them to allow you to use this approach?

Maarten: In the book I introduced some labels and I think that’s really useful, like the Anaconda style or the hummingbird style scrum to talk about uncertainty. What I talk about is what I call the fog of beforehand. So before starting, there’s just a lot of things you don’t know. And the only way you can figure out is just by doing the work, by stepping into the fog, encountering reality. And then the other part of it is if you spend too much time thinking then you introduce the fog of speculation. You inject your plans with noise, with incorrect assumptions. So the alternative is to have humble plans and that’s when you keep your plans grounded in reality, you take one step at a time and then based on what you discover and learn you adjust your plans and then there are roots in reality. We’re always so worried about our ability to predict, but I believe should be much more worried about our ability to adapt.

And that’s, I think the key conversation to have with leadership.

I found when I’m dealing with 

Murray: the business people who are responsible for real outcomes that they’re quite sympathetic to the idea that there’s a lot of uncertainty. And that we should focus on outcomes. Usually they do want us to focus on outcomes but it’s the delivery teams further away from the business outcomes who want to focus on outputs. Your finance procurement and IT leaders typically just want to focus on output. And I think when there’s a lot of uncertainty about the product and solution, there’s two different paths you can take. The traditional path is to say, we’re going to get rid of all of the uncertainty up front with detailed plans. And then we’re going to produce a lot of documents to get everybody to sign off. And then when it goes wrong I’ll be able to show that it was the product manager’s fault, not the IT department’s fault because they approved the requirements, and the changes. So that’s one way. 

The other way is to say that’s not going to work if you’re interested in outcomes. And so you have to focus on adaptability and achieving as much outcomes as you can within your budget, which is obviously where we’re coming from .

Maarten: I think you’re right. And I think the key thing as well is, if you follow the approach, you suggest the first one, then you have a glorious plan and you can hide in the rubble of all the documents and all the politics. But if you do it alternative, it will feel much more naked. And then when you don’t achieved results it looks bad. There’s not a glorious plan you can point to and you didn’t achieve the results. And I think that’s the key thing. It’s very scary because if you don’t have this magnificent plan, then people, feel like, Hey, you didn’t achieve the results. There’s no glorious plan. So now you’re going to get in big trouble because they can point out that you didn’t do a good job. You weren’t diligent and that’s why people don’t do it is there’s no glorious plan to hide behind.

Murray: In my experience, there’s a lot of IT executives who’ve never delivered a project that went well. And so their entire methodology is designed to protect themselves people start asking difficult questions. 

So to come back to stakeholders though I like your approach of including stakeholders, not managing stakeholders. and talking to them about outcomes, not outputs. That’s the way. I summarize what you were saying.

Maarten: Correct. And I think it’s really scary, because you’re actually going to sit with them in a meeting room and talk about, Hey, what we’re going to do. But I think it works much better than throwing documents over the fence and trying to manage it that way.

Murray: All right. So I think we should go to summaries. Now this is where Shane normally gives a summary and Shane’s not here today. So I’m going to try and give a summary of what you’ve talked about and then also give a reflection of it. So we’ll see how we go. 

Maarten: That’s okay. Thanks. 

Murray: You talked about why goals matter and why do we need to focus on goals rather than deliverables? And the reason is that there’s a considerable amount of uncertainty in the product development space, the software development space, digital. There is always far more uncertainty about how long things are going to take what even we need to do than, companies and managers are comfortable with.

And we can use the Cynefin model to explain that we’re working in a complex domain, or we could just focus on uncertainty. What’s really interesting is that this is a problem that’s been solved by the German army back in the 1830s, in Auftragstaktik , which basically means mission tactics. And, they solved it by using the idea of leading with intent which is goal based leadership. Although they focused on the very high level; setting goals for generals. But over time, it’s come down to much lower levels with NATO and, the US . If it works for them, why can’t it work for us?

And what you’re doing is, using , this approach to talk about, setting goals for sprints. People don’t realize that sprint goals have been around since 2013. Not many people have really been doing it. It’s still very common for people to be feature factories. So we can move away from a feature factory to be a goal directed, outcome focused group that achieves much better results if we focus on goals. 

And if we focus on goals, our planning can be much more lightweight. So instead of having detailed product roadmaps with deliverables that we’re going to commit to every month, we’re actually going to focus on goals in our product roadmap. Like at first, we’re going to increase customer leads and then we’re going to increase customer conversion. And then we’re going to increase the follow up calls we make to customers.

And then in the sprint, we’re going to take the product goal and break it down into a smaller goal that we can do in two weeks. And that goal is not to deliver these 12 user stories. That might be the way we implement it, but the goal is actually to, move towards the product goal in a meaningful way.

Maarten: Correct. 

Murray: So that’s always the outcome. I really like that approach because it means we can be so much lighter. We can go back to what people talked about originally in the XP days, which is a user story as a placeholder for a conversation. It doesn’t need to have a two page users acceptance criteria 

Maarten: The acceptance criteria can emerge. . 

Murray: Acceptance criteria can emerge during the sprints with everybody working together. So I really liked that. And it also means that the team and the product owner can ask themselves how can we move closer to achieving our sprint goal today? Not the number of points, but the outcome we want to achieve for the customer or the business. It means that they can be very adaptable. And the user stories that they thought they might do at the beginning You might not do those at all. You might do the first one and then realize you’ve got to do some different ones. And it doesn’t matter, does it? Cause the goal is the thing that matters. And the goal is not velocity.

Maarten: No, absolutely not. 

Murray: And then, we bring the goal into everything we’re doing. So in the review, when we’re talking to stakeholders, we say, here’s what we agreed. Our goal was in outcome terms, this is what we’ve done , to move towards that outcome, which we will be measuring, hopefully.

Maarten: Hopefully, 

Murray: And if we aren’t measuring it, that should maybe be our first goal is to measure it. 

Maarten: Otherwise you have a political shitstorm where everybody tries to claim it was their result. 

Murray: And then we have our retro, which is again about how did the way we work help us move towards our goal or not? So instead of just talking about all the usual blockers, we’re prioritizing the blockers by what was the impact on the goal. 

So then we’ve talked about some of the things that happen when you don’t use goals, that you become a feature factory, nobody knows whether you deliver outcome, you might as a result just lose funding and support. Although it might look like you’re achieving your deliverables your factory what’s the point if you’re not delivering any value to the business?

Maarten: Correct. Okay. 

Murray: This is really different to the way organizations work, it is very much the way that thought leaders are working today. It’s the way that elon Musk seems to work from our interview with Joe Justice about Tesla. Every day he’s asking, what did you do to move us towards our goal yesterday or last week?

I really like this approach. It’s much more flexible. I would really like people to do it. I think we can have conversations with our stakeholders by focusing on outcomes. 

I do think that it relies a lot on having a competent Team that you trust. This is really pushing us towards having a internal team that you’ve been working with for a while. And spending money to hire strong, competent people. 

Maarten: And I also think one of the strengths is by focusing on the outcomes, the result we’re trying to achieve in every event, then we’re actually talking about, Hey, this is, what we’re trying to achieve versus we’re trying to achieve scrum by the book. 

Murray: I agree with you. And then Scrum can just be a continuous improvement mechanism. Fundamentally, Scrum is about saying, we want to achieve this goal, in the next two weeks . And then at the end saying, did we achieve it? What can we do better? That’s just continuous improvement with a time box.

Maarten: Correct. 

Murray: And people to get very hung up on this definition of ready and velocity and user story points and all that sort of thing. So I like this. I think it’s very freeing because it’s very outcome focused. So it’s quite liberating.

Maarten: That’s how I believe it should be like with a sense of play, but then without people calling you a child.

Murray: The best work gets done in the state of flow and innovation gets done when people feel that they can play with different ideas and experiment.

All right. So it’s called Driving Value with Sprint Goals.

Maarten: So you can find it on Amazon, you can find it at Pearson. Search for the name and you hopefully will find it. And if you don’t, then you can always message me and I will help you out.

Murray: and is there a website? for the book? 

Maarten: No there isn’t. It’s on my website you can find it. But I don’t have a separate website for the book. 

Murray: What’s your website? 

Maarten: Dolmine. com with a Y, so I will share it 

Murray: D A L M Y N dot com. 

Alright, good. And are you doing training or consulting on how to implement this goal based approach?

Maarten: Yes, absolutely. So I give trainings, workshops, presentations.

Murray: But you’re based in Netherlands, though, so presumably you’d like to work in that time zone.

Maarten: Preferably but I have some US customers as well, so it depends. Alright, thank you very much for coming on, Martin. I really enjoyed it.

Me too, Murray. Thank you.

Murray: That was the No Nonsense Agile Podcast from Murray Robinson and Shane Gibson. If you’d like help to create high value digital products and services, contact murray at evolve. co. That’s evolve with a zero. Thanks for listening.