#NoEstimates Business Applications with Vasco Duarte

Welcome to Amazing Apps Applications podcast from Microsoft, Dynamics 365 and Power platform application builders who want to build amazing agile business apps that everyone will love. 

 Hi, I'm your host, Neil Benson. Welcome to the Amazing Apps show. If this is your first time here, a very special welcome to you. My mission with this podcast is to help you slash your project budgets, reduce your delivery timelines, mitigate technical risks, and create amazing, agile Microsoft business applications. With this episode, we're kicking off a season of interviews with Microsoft customers and partners who have built an amazing application, we’re uncovering their secrets so that you and I can learn from their success. The guest on today's show isn't a Microsoft customer or partner, he's Vasco Duarte, he runs Oikosofy, a coaching company in Finland. Vasco speaks six languages. He publishes a podcast episode every day, the Scrum master Toolbox podcast. And he's also author of a fascinating book called No Estimate's. Vasco and I chat about the challenges of estimating complex business application software, particularly in the CRM and ERP domains, and how the No Estimates movement and the method covered in his book can help business applications teams construct collaborative contracts with their customers and never deliver late again. 

 At the end of this episode, I'll let you know how you can win a free copy of Vasco‘s No Estimates book. I loved it so much, I bought 15 copies, so I've got 14 copies left that I'm going to give away.

 For show notes to this episode, including links to the resources Vasco mentions a transcript of our conversation, and to enter the giveaway competition, visit Customery. Dot com slash zero two three as the word customer with a Y on the end dotcom slash zero to three. Here’s Vasco Duarte. 

 Vasco, welcome to the Amazing Applications podcast. It's great to have you on. Thanks so much for joining us.

 Absolutely. Neil, thank you very much for having me. It's a pleasure to be here.

 What do you like to do just to get to know you a little bit better and to help our audience get to know you a little bit and your background? I got three little questions for you. What did you have for breakfast this morning is number one?

 I like my breakfast reliable and delivered on time, just like I like my software. So, I went for coffee and toast.

 Very good. So, it's nice and healthy and simple. Good. And what was your first ever job?

 So, my first ever paid job was actually working at the university, managing the local computer network, which this was way back when in like 97, I believe. So, managing computer networks was exciting and new. But my first job as an employee was as a software developer for a we could call it I.T. security company. It's F-Secure up here in Finland, the north of Europe. And I did the software development and project management. So that was my first let's call it real job.

 OK, what's your role today?

 So today I work with teams all over the world kind of trying to help them achieve something that I'm pretty sure your listeners also want to achieve, which is reliably deliver software on time. And I'm sure we will come back to that several times in this show. But the idea is that no matter how many years we've had in terms of agile adoption, we're still very, very far from where teams think they should be. And this is themselves thinking where they should be. So, there's a lot of work there within the software. And my focus is product development. So, software development and product development to work with teams and help them reach a state where they feel that they are at a high level of performance on their own terms. Right. In their own definition and in the context of their own business.

 So, I got to know your best through your daily podcast, The Scrum Master Toolbox, which I would encourage all my listeners to go out and subscribe to. It's a great show. You've got some wonderful guests on there. But I also know you as an advocate of I guess it's a movement with a curious hashtag, #noestimates, which is you can correct me if I'm wrong, but I think it's an untruth. There are estimates even in the no estimates movement, but it's a better way of proposes, a better way of estimating software. Just before we get into that, I just want to let you know my background against my prejudice, because I grew up in the UK in the 1980s and there was a game show host called Bruce Forsyth. And one of his famous catchphrases was, as I watch the show, I play your cards right, I think it's called. And he would shout, what do points make? And the audience would shout prizes. So, I guess I grew up believing that if I used points, I would get prizes. Well, what's wrong with estimating in points Vasco?

 And that's a very good question. Not just estimating in point, but in points. but estimating in general is not just wrong, it's a horrible business strategy. Let me get back to a little bit what the core of the movement is. Right. So, without yet going into the details of, you know, are there any estimates? And if there are, what kind and if not, then what's the alternative? Right. We'll get into that later. But the root of the movement was that many of us were and still are frustrated with how unreliable and how late software projects usually get delivered. So unreliable in the sense that they don't deliver what they promised, they don't deliver when they promised, there's quality problems, that there's people that promise things, but they don't actually, in the end deliver what they promised. We need to wait until the end of the project to get what we expect it to get. And there's all kinds of problems with software projects. So that's where it started. You know that frustration and through our own practise and experience, also by using agile methodologies like you talk about in your podcast, we discover different ways of doing it than just like the manifest that the agile manifesto says right at the top where we're doing and discovering better ways of delivering software.

 So that's what No Estimate's movement is all about. Now, some people will argue that there are still some estimates in no estimates. My perspective is that estimation is a failure mode that should be avoided at all costs. And therefore, of course, we will talk about alternatives and what to do instead. And let me explain why I think it's a failure mode. So, the estimation experts themselves, they say that a successful project is delivered within twenty five percent of the estimated date. So, they basically say that if you're within 25 percent of your estimated duration, 75 percent of the time, it's still considered a good estimate. Now, if you're doing the calculations mentally, that is the same as you going to an investment banker, giving, you know, your hard earned 100,000 Aussie dollars for him or her to invest. And the investor would turn to you and say, you know, because I'm a great investor, Neil, I'm really good at investing.

 Therefore, I will only lose 25 percent of your money. And that's with a 75 percent chance. I mean, I might lose a lot more, but, you know, that's unlikely. Right.

 And when you put it this way, one has to say, I think it is rather irresponsible to use estimates as an investment strategy, because at the end of the day, that's what we do with software. We invest in software to get some value out of it. And if we start right at the top by accepting that we're going to lose 25 percent of our money, you know, 75 percent of the time, we might lose a lot more, I think we're going in the wrong way. So, we need a new way to deliver software. And that's really what the core of the No Estimates movement is. We need a new way to deliver software that does not rely on estimates, even, you know, if, God forbid, you might still use them.

 So, there's no escaping there’s two questions that every stakeholder or project sponsor asks us, which I think we have a right to or an obligation to answer, which is how much is it going to cost and how long is it going to take, whether we're going to estimate or do something else? We need to answer those two questions. Would you disagree with that?

 So, first of all, the questions that they are asking, although they might come out that way, what they are actually asking us is don't spend more money than I give you and have something delivered by the time I need it. 

 Right. 

 Right. And you know this very, very well. I mean, in your domain CRM and ERP, you never get the whole functionality at the end of the project anyway. I mean, you spend years developing those systems. I mean, not just maintenance, like, you know, adding features, adapting to new changes in legislation, maybe new products, whatever. There's always going to be stuff that we need to do. In fact, we know that successful software projects are the ones that never end.

 And if you think about estimation and this aspect of continuously delivering value to the customer, you start to think that wait a minute, but estimates put us in this lose-lose scenario where we know we're going to be wrong. We just don't know by how much and the customer is going to be mad at us. So, we're going to go and transform this into a lose-lose contract, which is the fixed price fixed scope contract, because, of course, the customer doesn't get what you what they want, and you end up paying for it. So, we need to transform this relationship into a win-win relationship with our customers. And here's a very simple example. And I'm, of course, exaggerating, but there's plenty of content out there that I challenge the listeners to go and find it.

 For example, lean and agile, financial planning, extreme contracts, agile procurement. There's loads of information out there on how to build these contracts. My own favourite is the extreme contacts perspective that I'm just now sharing with Neil on video, but it's unfortunately only available in Italian. So, I guess not available or not easily reachable for most of the listeners.

 But these trends in the agile world, pardon me, are all about how to build these relationships so that we start building value for the customers with the customers from the start. So instead of having a six month project, which you need to commit to, and you need to promise you're going to deliver on time, and you need to promise you're going to deliver exactly what you promised at the beginning of the six months. We say, all right, we'll actually say that the maximum investment we're willing to put into this is X, let's say, six months. And the money that goes along with it because, you know, in software projects a lot a big part of the investment budget is how long do we go with the project? But we also say that every week we're going to deliver something valuable. We're going to review if that is indeed valuable for the customer and we're going to tack we're going to change direction if it isn't. And not only that, but in extreme contracts, they even propose that the customer might decide not to pay for that week.

 Of course, now we're talking about paying every week, not, you know, at the end of the six months, which is also more sustainable both for the customer and for the provider, the vendor, the software developer.

 And we're saying that there's a responsibility on both sides. Both sides win from this relationship, but they also bring responsibility, or this relationship brings responsibility to both sides. The vendor is promising to deliver value every week and showing what they have delivered. And the buyer is promising to review and approve, accept everything that was delivered that week. And if they don't, they don't even need to pay. This is a win-win relationship. This is what Agile was all about to begin with. And in this case, the only thing you need to estimate and I'm using, like know, very big air quotes here is how much money is the buyer willing to spend and that you don't need to estimate the way we estimate software project. You just look at the balance sheet, you look at the value you expect to generate, and you just put a price tag on it even without knowing what software will come out of it. Then, by the way, and this is the most surprising part. This is actually how most projects get funded. Somebody comes up with a number, they say, I think they should cost a million. And when the vendors come in and propose a project of one point five million, what happens? You bargain and you end up around one million. Maybe you go over a little bit, but probably not that much. And that's just how software gets priced today, already without estimates. But then we give that to the software development team, and we tell them, oh, by the way, here's the full list of features and we already know the price even before you estimate it. So, make sure your estimates fit the price we have to deliver.

 It's fascinating. You've played out a scenario there which I've seen a dozen or more times in the Microsoft Dynamics World, Microsoft power platform world, where customers have a procurement process which says here's a requirement specification go bid and a number of systems integrators will come back with bids and they'll be all over the place. And normally the customer will choose one that they like the sound over like the look of, and then squeeze them into the budget that they already had, regardless of the vendors proposed costs. And we end up with this very antagonistic procurement and engagement process. My preference I love working with customers to have a fixed budget or a fixed time scale. And we say let's build as much value as we can, and we'll review it every couple of weeks. And after any of those reviews, if you think that the next iteration is going to cost more than the value, you're going to get from it, then we're done. The project is over. And the product is built at that stage. Hopefully, we can keep going for a long time, but, you know, it's up to you, Mr. Customer, to manage the scope, manage the budget, managed the time scale and tell us when we're done and the projects that I have delivered in that partnership have been far more successful, rewarding, professionally enriching than the antagonistic ones.

 So absolutely. I should put you in contact with Jacopo Romei the author of Extreme Contracts because he probably wants to interview you and feature one of your stories in the book as well. I mean, he is doing now, he's writing the English version of the book.

 And what you described, by the way, Neil, is probably, is also potentially the projects that have made you happier as well. Right. Because the worst thing for a software team is to work on a project delivering value or delivering functionality, they know has no value just because it was in a contract. Right. Like no one likes that. The customer doesn't like it, but they signed a contract, so they have to pay for it. The team doesn't like it because they know that software will never be used, and it doesn't actually do anything useful now that they understand the business better. And we are stuck in that lose-lose relationship. And that's what we want to avoid with no estimates, is step out of the price haggling. We already know there's going to be a cap on how much money we're going to get because that is dependent on the customer's business. It's not what we think the software cost is, how much the customer can pay for it. Right.

 That’s right, they’ve done a business case. They know the improvements in productivity or the increase in sales or whatever. You know, the business value they're going to get. They they've quantified that already and they just want to spend some amount less than that on the software that's going to get them those outcomes. So, yeah. All, for that, you've said there's three reasons we should stop estimating because we suck at it. Estimates put unnecessary pressure on our teams and the process of estimating wastes a lot of time. Now you can go in one of Mike Cohn’s training classes and learn how to get better at estimating. There's a quote here from an author on Medium. He said that one of the benefits of no estimate, this is a guy called Maarten Dalmijn. He said one of the benefits of no estimates is that there's no velocity so that there's no management pressure to keep increasing velocity, which can pave the way to focussing on value instead. But he said that the organisations that put the most pressure on their team’s velocity are the ones least likely to adopt no estimates. Do you think that's fair?

 Well, I don't know that I have worked with many different types of organisations. Some were more likely to adopt a method like no estimates than others. But I do want to take Maarten’s writings and make a point based on that, that you can still have velocity even if you don't have estimates. The number of stories isn't delivered by per sprint. This is one possible definition of velocity. And you can't really avoid pressure from whoever in the organisation, product managers, managers, leaders to increase velocity.

 Like you can't avoid that because that's what's implicitly in our subconscious. Even, you know, make it faster, make it faster. But the problem is that the velocity thinking main problem is that it assumes that delivering more things is better. And in some cases, it will be, but in most cases it isn't. Then we know that there's plenty of service out there that show that the majority of the functionality in any piece of software is rarely or never used. So, in fact, we know, and we know from practise, and especially you, Neil, who works directly with customers and sees how they use the systems you develop. Majority of functionality is actually not necessary.

 So, we need to create a way of working that discovers what is actually necessary by making it expensive both for the customer and the team to add more functionality. And what that drives us is to minimise the functionality that we introduce, therefore hopefully maximising the value we get out of it. Right. So, if you can deliver a system in two weeks, why would you work three weeks? Because it's in the contract. It makes no sense. So, I think that the velocity thinking biggest, and the pattern and biggest risk is that it prevents us from even starting to think about the value and it forces us to think about more things equals better even when it's not the case and we know it's not the case.

 Well, I'm a big fan of Scrum, but I think one of the downsides of Scrum is there's an implicit sense that the only person responsible for looking at value, maximising value, considering what's valuable, is the product owner and the developers stay out of it. The developers respond to the product owner’s prioritised backlog and do what they're told, which is not the way I enjoy working. I enjoy the cut and thrust of debating with the product owner which features are going to create value, and like you say, which features are going to add no value at all, maybe more complexity. They're unlikely to get used. And particularly in our line of work, building business applications our product owners are quite often first time product owners. You know, they're the chief financial officer or the head of sales. They've never built software or been part of a software development team before, so they've got a naivety about, you know, fitting in as many features as they can to please the rest of their stakeholders. Do you think developers need to step up and do more to push back on what's valuable?

 Yeah, I think that's there's a kernel of truth there that I would like to explore further. So, I do agree that developers need to step up, but I want to say that they need to step up in a very specific way. So, like, for example, in your case, you probably in your company have developers who understand very much about the ERP and CRM and whatever.

 Right. But they don't necessarily understand the customer's business. So, here's how I think developers need to step up. Developers can bring to the table the creativity they have applied to the technology tools to create solutions, but they don't necessarily have enough knowledge of the customer's business in order to bring that. So, they need to be part of the dialogue. Right. The problem starts with the idea that the customer already knows the requirements. Right. And a famous Steve Jobs quote is, “It’s not the customer’s job to know what they want”. It's our job to know what they want. It's the customer's job to know what problems they need to solve. And this in here in lies the critical interaction I have in the podcast, the Scrum Master Toolbox podcast. On Thursdays, I talk about this Product Owner e-course, which is a course not for Product Owners, but for Scrum Masters to bring the Product Owner together with the team so that they can co-create the solution.

 And especially in third party development, business relationships like you’re in, and like many, you know, application developers are in today.

 We need to bring the customer and the development team together to develop the requirements. So, my challenge to people in in your business, Neil, is have a conversation with the customer established business targets that you need to help them reach its the business targets that matter, and then, of course, work with them to figure out how they can adapt the software to their processes or change their processes, if that's, you know, the best way to go in order to reach their business targets. And here's the thing. In no estimates, we very often talk about this. We talk about bringing value and creating value together with the customer. Why? Because when we are creating value together with the customer, when we're challenging, challenging them and say, you don't really need a Microsoft Word style text editor, you could probably survive with a simple notepad style text editor with just a few more features. And you know what? It took Microsoft 15 years to develop Microsoft Word. So, it's likely it's going to take us a lot more because we're not Microsoft. But on the other hand, if you want notepad, I can deliver that tomorrow and then we can start developing that and making that better, you know, every day or every week, whatever the period might be. So, for me, this is the challenge is bringing the developers to the business so that they can co-create. But of course, the main difficulty to this is the expected kind of constraint, if you will, that the customer must know all the requirements before we get started. And if that's how we start, the relationship developers can't do much. I mean, they become shopping list managers, right? Give me the list. I'll do it.

 I fight against that fallacy of the upfront requirement specification all the time. I tell my clients that those documents are normally written at the point of peak ignorance when they know least about the software that we're about to build for them. And I and the development team of the developers know the least about their business. And we set these things in stone. We build an architecture design around them. We build a GANTT chart around them and off we go into oblivion. So, yeah, trying to get away from that idea of the possibility that it's possible to define all the requirements up front. I just think it's a lunatic fallacy. Maybe I'll give you an example of a situation I'm in at the moment, but I'd love you to walk us through how a no estimates process works when I'm just about to launch a new project. So, I don't have an upfront requirement specification. But the customer has an idea of the business challenge they're trying to solve. And maybe we've done a workshop for an hour or two just outlining the top features that we need. I'll give you an example. Just reading some of my notes. I have a local customer here. You'll enjoy this. They're 18 months into a six month project. 

 I've been there many times. 

 You've been there? Yeah. They parted ways with the first systems integrator they had, and they have nothing to show for that. Phase two is about 12 months late. Sorry phase one is 12 months late. Phase two, I'm trying to help them plan for 63 requirements. And because I'm old, habits die hard. I took the developers through a story point estimation exercise, and we came up with about 1200 story points and we forecast the velocity of about 40 points per two week sprint. So, we think it's going to take about 30 sprints. It's about 60 weeks. So just over a year. How would I approach that exercise differently using a no estimate's method? I'd love to find out how you put it into practise.

 Yeah, absolutely. So, let's start with that, because that's actually the story of the book. So, in the book, we have the story of Carmen, a project manager who just got handed a project pretty much like the one you described, that, you know, it's too far into the future to know what's really going to happen, but it's somehow critical for the company. And that's the important part here, because if it's and if it's a non-critical project, forget about it. Use estimates, use whatever you want. It doesn't really matter. We're talking about critical projects that can make or break a business. That's what we are talking about here. So, she starts by using story points. You know, that's a good step to start. OK, we have an idea of the size of this now. Expect the size to be 100 to one hundred and fifty percent wrong. If you can't survive an estimate being 100 to 150 percent wrong, you're going to die anyway. So, expect that from the start. Now, don't let it happen that way. And that's where the next steps come in. Right. So, step number two that Carmen goes through is that she stops estimating tasks. There's only estimates at the high level. So, at the story level or feature level, whatever you might be using.

 And as I give up task estimation ten years ago as an exercise in futility, at least I've got one positive step forward. Good. 

 That's it. Well, there are still many teams estimating that that's good that you got there already a few years back then. The third step is at some point you need to accept that estimate for four stories and features are also wrong. So, you start using a technique, this very old technique from critical chain product owner project management, which is that you limit the duration of those tasks. So, in this case, for example, let's say you have a story that is how much points do you think you can deliver in the sprint? 

 Forty. 

 OK, so let's say that you're that you have a story that is a little bit over 40 points. Whatever you say, we're not going to invest more than one sprint in this story, period. Right. So, we need to make this story happen this sprint, even though we estimated to be longer. The reason is not to go against the story as it was defined. The reason is to challenge the need for all the details that are now in the story. So, one thing that you might do is that you go through the acceptance criteria and you say, well, in fact, if we just deliver these first five acceptance criteria, we're good to go. So, you now split that story into two, the one story that has the first five acceptance criteria and the second story, which is the other acceptance criteria, if you want to take this to the next level. Neil Killick, a fellow British person who lives in Australia, coincidentally talks about using this slicing technique, which is take one story, break it into as many acceptance criteria as you have, and start delivering that one by one.

 Right. So, this is one way in which we limit the duration of stories to the calendar time we have, in this case, a sprint. And then what she does, what Carmen does in the book, is that she reduces the allowed number of estimates. So, for example, you might say to your team, anything that is bigger than a five we’ll cut it down in half. And it doesn't matter what the what half is bigger. Right, I’m using half here in quotation marks. We just cut it down in two. So, if a story is a seven, we cut it down in two. If it's a 13, we cut it down in two. If it's 20, we cut it down in two. It doesn't matter. We always cut it down in two and we only accept stories that are believed to be up to five. Then you start tracking your data. How many stories did we deliver last sprint and the sprint before? Once you have three sprints, you're good to go. We start using data and we start only counting the stories. Now, you've done a lot of this already. You probably have limited, even if implicitly, the size the story point size of the stories you accept to be, you know, unique deliverable stories. Right! So just start tracking data.

 If you have a project of a year, it only takes three sprints. That's six weeks in your case to have a pretty good idea of how many stories you’re going to deliver. And that's what Carmen does in the book, she just starts following the stories that are delivered every sprint, tracking that against the Burndown, a very old Scrum tool, by the way, Burndown with now two lines, the line that is the optimistic delivery. So, you take the maximum amount of stories delivered in a sprint and you plot that the pessimistic delivery, you take the minimum amount of stories delivered in a sprint and you plot that. Then you now have what we call it in the old project manager world, a landing zone. Right. The project will land between these two points if nothing else goes wrong and if the backlog doesn't, in the meanwhile, explode in size. 

 Right. 

 But if it does explode in size and this is the cool thing, you don't need to sit down the developers and have another mindless, boring, super detailed estimation meeting on backlog items that might never be implemented. So, it's a win-win for everybody, right? This is the seven step journey to no estimates that I talk about in the book, no estimates book that describes all of this in more detail. But this is one way in which you can ease into it, even if you've started with the story point destination like you did.

 Ok, it sounds like I’m along the right lines. I maybe didn't need to take the developers through what was actually quite a painful exercise. This is a developer, set of developers that have been delivering late, right. So, they're under a lot of pressure. They don't like estimating because people now put pressure on them to stick to those estimates. And I can understand their reluctance to make any kind of commitment or forecast. So, it was much more painful than it would normally be. But we got there at the end if I just worked with my product owner and we had a business analyst as well. What you're saying is carve up my items, cards, user stories. But if we're using to be roughly the same size, we don't we don't even need to know that they are the same size.

 We just need to have a gut feeling if they are bigger than one sprint and then cut them in half. And that's it. That's the only question you need to ask. Now, some people would call this an estimate. The others would call this Blink estimates. I call it using your experience and knowing when you're in trouble. That's what I call it. Right. So, for us, for an agile team, if a story is bigger than a sprint, you're in trouble. Cut it in half.

 When it comes to delivering within a sprint backlog, do you think there's an appropriate number of stories to take into a sprint? I've heard some people say, oh, each developer in your Scrum team should be working on about four stories in a sprint. We're talking here at a conceptual level about the Scrum team working on a single story in a sprint. Is there a recommendation or rule of thumb you have that has worked well in practise?

 Yeah, so there's two extremes here. Like everybody's working on a different story and everybody is working on the same story. These are the two extremes. And at some point, in your project, maybe there's an extremely difficult aspect, technology, speaking, technologically speaking, you may want to have the whole team working on the same problem. And then then it's the whole team on one story. On the other hand, there's at some points in every project, there are these, you know, mind numbing, small things that need to get done. And you just need to get through those or as many of those as you can. And maybe at that point you want everybody to work on a different story.

 I mean, the team is also smart enough to know when they need to be, where do they need to be in the spectrum. So, in the Scrum Master Toolbox podcast, we very often use the phrase “take it to the team”. Right. If you if you have a bunch of things that you need to go through and, you know, it's just we can't avoid it. It's legislation. We just have to do this. You take it to the team and say, guys, how can we do this the best way? And some will say, well, I can take these two and the other will say, I can take these two, or maybe some of them will say, hey, we need to work together on this one, but the others, we can just split it up and have everyone tackle one like the team knows. Right. The team is smart about how to do the work. So, bringing that to the team is also an asset for a team lead or a product owner is bring it to the team and say, here's what we need to do. How can we best do it? Then they'll know where to be on that spectrum. Now be careful of anti-patterns. If the team always wants to be on the side of one story per developer, they probably don't want to talk with each other. There's probably some collaboration problems there. Yeah, if the team always wants to be on, everybody works on the same story, it might be that they are not really understanding the importance of delivering more things. So maybe we need to talk about the value of the stories and why some stories need to be delivered now rather than focussing on only that one that everybody likes. And it's, you know, technologically challenging and interesting that also happens. That's an anti-pattern, right? So, we need to be aware of this, but usually take it to the team. The team knows how to help you decide where on that spectrum you should be.

 One of the benefits I've experienced through backlog refinement workshops and estimation workshops is the exercise itself is valuable in reaching a shared understanding, the product owner discovers gaps in his or her thinking in the product. The developers find out lots more about the product they've got to build and the value it's going to create for the organisation. Is there a risk that if we go ram shod really quickly through estimate one with no estimates, that we miss that shared understanding and there's an opportunity wasted there?

 That's a very good question. So very often one of the pushbacks I get is that if you don't estimate, you don't understand the story. So, let me give you a different process to create not only good understanding, but much more important understanding than what usually people think we should have. It goes like it's called the Clinton process, which I talk about in the no estimates workshop. It's named after one of the people I interviewed for the book, Clinton Keith, a software developer, a games software developer that uses Scrum and who's also a no estimates pioneer. And it starts with the very simple phrase, and it's like this, whenever somebody says, hey, we need to do this story this way, you know, like they describe a solution, you should always start or you should continue the conversation by saying, yeah, that's a great idea. But, you know, we don't have time for that.

 And then you follow that up with, wait a minute, why are we discussing the solution? What is the real problem we are trying to solve here? Right. And once you understand the problem, that's what shared understanding, that's the kind of shared understanding that matters is what is the problem we are trying to solve here. Once the problem is understood, you make sure that you give yourselves the team gives itself a ridiculously short time box. That's one of the amazing revolutions that came with the introduction of Scrum and time boxing in general. So, in Clinton’s story, he says the team gave itself one sprint, two weeks to come up with a solution. Right. Not to understand better the problem, because they did that at the start of the sprint, but to come up with a solution that would work within that time box, the two weeks’ time box, and then they did, this is the fourth step and the most important. Instead of testing, does this feature work, they tested, does this feature deliver the value the customer needs?

 And they did this by actually testing with users and getting their feedback. So instead of saying, yeah, we've ticked off all the acceptance criteria, we've run the tests, everything is good. They said, no, no, wait a minute, let's show it to the users themselves and have them tell us if we actually solve the problem. Here's an example that could happen in your projects, Neil. This is a friend of mine is right now we're writing a book for Agile Business Intelligence. So, they you know, they do a lot of dashboarding, for example, which I imagine you guys also do.

 Yes, there’s a lot of Power BI listeners, all building dashboards today. 

 Exactly. So, one of the things that they do, Raphael Branger of IT-Logix in Switzerland, one of the things they do is that they mockup the dashboards in Excel. Now, many of your listeners will probably know that's a hell of a lot easier. So now the only problem is where do I get the data? Well, then there's the APIs you need to get the data from, you know, whatever a data lake, a data warehouse, whatever that might be. Well, no, wait a minute. You don't need all of that.

 You just need a snapshot of the data in a CSV file and then you import it to excel and you mock the dashboard. There you go. Now, you can actually show the end product, the dashboard in less than a week, get direct feedback before you spend all of the time figuring out the API, setting up the systems and all of that. That will eventually give you the data access you need to show the dashboard, but you're testing for value. And that's the fourth step of the Clinton process. You test for value. Now, here's the thing. If you do these four things, we don't have time for that. Wait a minute. Why are we talking about the solution? Why don't we understand the problem? First, give yourself a ridiculously short time box and then test for value. If you do those four steps, you're going to get a hundred times better understanding in one tenth of the time you would otherwise. So instead of spending time estimating, have that conversation. Wait a minute, what's the problem we're trying to solve? And by the way, how can we test it fully tested for value end to end value test by the end of this sprint?

 It sounds like the old Spike concept from extreme programming, where we brainstorm a couple of ideas, maybe prototype two of them show both to the users which one of these meets your needs most closely. And those would be a rough prototype that would really inform the user story that we're going to write and deliver in production in the following sprint. But we do that within a time box just to try and uncover better solutions for the business problem that we're faced with. Pretty sure Kent Beck would have called that a spike back in the early, early 1990s.

 Yeah, absolutely. And it is and this is the important part. It's a spike centred on solving a problem for the customer. It's not a spike centred on a technology problem. You still need those as well. I'm not saying otherwise, but this is a specific focus on customer value in a very short time frame. Even if it's not the full solution, it proves to us. We do understand and this is the point that I wanted to make, it proves to us as a team that we actually do understand the customer problem because that's what we need to understand. It's not the requirements. You'll figure that out on your own if you understand the customer problem. And very often we flip this, and we focus on understanding the requirements without understanding the problem. And you know what happens? You deliver a solution. Nobody likes late and over budget.

 Vasco, this has been a fascinating conversation, I think we've blown a few minds in the audience. I've got an ask for you. I bought a bundle of your books, the No Estimates. I want to keep one. I still haven't read it all yet. You can tell I've watched a lot of your content. It really is mind blowing for me and I'm sure it will be for the audience. Do you mind if I run a little giveaway competition to give away the other copies of your book that I bought? And can you tell us where everybody else can go to get a copy of it?

 Yeah, absolutely. So do participate in that giveaway that Neil just announced. Thank you very much for doing that. And you can get the book at no estimates book dot com or of course, on Amazon.

 So, it's only available digitally, so you will not be able to get it in print. I am showing a print copy to Neil, but this is very much a preview copy. So, it's not yet available in print. It's only available digitally, either directly from our company at no estimates book dot com or from Amazon.

 Any plans for an audio book version?

 There isn't a plan for an audio book version. In fact, there is a plan for a second edition, which would be the first in print.

 But there's, I believe, something like seven hours of audio content already, audio and video content already. If you buy the full digital edition available at no estimates book dot com, there's interviews with seven people, pioneers, as well as practitioners of no estimate sharing their stories, including CEOs of companies pretty much like yours, Neil, people that own companies that deliver software to others and how they use no estimates.

 Good stuff. Well, Vasco, thank you so much for coming on. I've really enjoyed the discussion today and we'll catch you next time.

 Thank you very much, Neil. Thank you for having me.

 Come on, admit it, you've got to be just a little bit curious about how you can always deliver projects on time, never miss a deadline, always deliver within your stakeholders' budget and all without never producing an estimate. I know I am. Vasco’s No Estimate book includes the book itself in PDF, mobi and EPUB formats is the ultimate guide to capacity planning and agile contracts, mini books, and a bunch of his keynote presentations. You can pick up your copy at No Estimates book dot com or you can enter my give-away, where 14 winners will get a copy for free. To enter, visit Customery dot com slash no estimates. Winners will be notified shortly after the giveaway closes on the 19th of March 2021. Good luck and keep sprinting. Bye for now.