Why Estimate Business Apps At All?

Neil Benson: [00:00:00] Welcome to Amazing Applications episode 127. G'day, I'm your host Neil Benson from Customery and I can say g'day now because as of last week, I am officially an Australian citizen. Woohoo. G'day mate!

You'll find show notes with helpful links and a transcript of this episode at https://AmazingApps.Show/127. 

In this episode, and probably over the course of the next few episodes, I'd like to give you a sneak peek of my new Estimating Business Applications course. The course is designed to help anybody involved in building business applications, particularly involved in estimating -- everyone from sales or business development through presales and delivery -- with a structured, proven set of tools to quickly, accurately and confidently estimate how long it'll take and how much it'll cost to build a Microsoft business application your customer is looking for. 

And, if you work for a Microsoft customer, you probably get the same questions from your stakeholders, whether you have a Microsoft partner helping you or not. So you'll find the course useful as well. 

What you're gonna hear in this episode is part of the welcome video and five lessons from section one, titled "Why estimate at all?" There's a link in the show notes at https://amazingapps.show/127, where you can join Estimating Business Apps for free. You'll get access to those video lessons, and you can take the quizzes to test your understanding. Until then here's the taster or what you can get inside the course. Enjoy.

Welcome to Estimating Business Applications. G'day and welcome to Customery Academy. Thanks so much for joining me in this Estimating Business Applications course. My name is Neil Benson, and I'm on a mission to help everyone build amazing, agile business applications that your [00:02:00] stakeholders will love. It's great to have you on board.

I'd like to spend a moment helping you become familiar with the course so that you can get the most out of it. The course is organized into sections and . The lessons are all video lessons or quizzes. Under the first video in each section you'll find recommended resources, such as blog articles, podcast episodes, and YouTube videos relevant to that section.

You'll find a discussions area at the bottom of each lesson where you can leave feedback, ask your questions, share your experiences, and participate in the conversation with other students. There are quizzes at the end of most sections to test your understanding. 

Customery Academy courses are available through a native mobile app for Android and iOS devices, developed by my course platform provider, Zenler. Visit the Google Play store or the Apple App Store and search for Zenler: Z-E-N-L-E-R. Then log in with your Customery Academy credentials and you'll have access to the course from your mobile device. 

At the end of the course, you'll be invited to leave a video testimonial. I hope you enjoy the course, find the content useful and you'll record a short testimonial so I can share your experience with other business apps professionals.

Are you ready to get started? I'm here whenever you need me just post your questions into discussion area under any of the lessons. Let's go.

How much and how long? 

They are the two questions that every business applications professional dreads hearing: 

How much is it going to cost? 

How long is it going to take?

Followed closely by: When are we going to be done? But we'll address that one later. 

To address those first two questions accurately requires an uncanny ability to predict the future. Most of us don't have the ability to forecast the future. I bet you my crystal balls are smaller than your crystal balls. [00:04:00] The software industry is renown for being crap at answering those two questions. We regarded nearly as poorly as the construction industry. 

But the thing is: our stakeholders want us to answer those two questions. They need us to answer those two questions. They deserve the answers to those two questions: how much and how long? No one in their right mind would approve a business applications project with an unlimited budget, that could take forever. They've got business cases to make, investment committees to persuade, and sometimes they have to appease the penny-pinching paper-pushers. 

I wouldn't approve a project in my business without some understanding of how much it's going to cost and how long it's going to take. I don't expect my stakeholders or yours to do that either. 

I wish we didn't have to estimate how long and how much. A better approach is to assemble a team, start building a few features, and then use the data to forecast how long and how much is required to build the rest of the features.

But our stakeholders often need us to produce an estimate before we start work so that they can evaluate a business case against other investment opportunities or evaluate prospective Microsoft partners who have proposed to build the application. 

In my experience, estimating is an essential activity. But it's not always a valuable one. Nobody wants to spend two or three times longer estimating than they do today. Quite the opposite. It's essential, but we want to spend as little time and effort as possible creating accurate, useful estimates that our stakeholders love. So that we can get on with the fun stuff: developing business applications that our users love.

Estimating requirements has bought one big benefit to my team, that is a shared understanding of the requirements. By estimating together as a team, we have an opportunity to discuss them, [00:06:00] hopefully with the product owner, note our assumptions and creating an estimate. Different team members bring different perspectives and experiences to the estimations, which makes them more robust. And the team begins to buy in to meeting the customer's requirements. 

The estimation method I'm going to share with you in this course, story point estimation, is a popular alternative to the traditional method of analysis in advance and upfront design. It has worked for me and I'm confident it'll work for your team too.

 There are other estimation approaches. There are more sophisticated, probabilistic methods available and you'll find links to resources about more radical methods in this course. 

There are two reasons why I recommend story point estimation for business apps professionals, like you and me. 

(1) Story point estimation is simple, it's quick, and it's often good enough for the estimates we're asked to provide. It might not be as accurate as more sophisticated forecasting methods, but it's good enough. 

(2) You can use a story point estimation, even when you have no empirical data. The accuracy of your story point estimates gets better once you start delivering features and accumulating actual data. But you can put produce story point estimates even for projects that haven't started yet, which I've found essential when I'm bidding for projects in competitive situations. 

Before we find out more about story point estimation, let's find out why estimates are notoriously inaccurate.

The traditional method of estimating the cost of a software project looks like this. 

First, capture all the requirements up front. Maybe the customer has sent you a requirements specification as part all the request for proposal process. Or maybe you've been engaged to produce the requirement specification as part of a discovery process.

We're going to interview lots of people, analyze lots of stuff, figure out what everyone needs and write it all down [00:08:00] in as much detail as possible. If you forget something or get something wrong, there'll be a nasty change request later. So you better get it right first time! 

Next, design the system. Figure out all the components needed to satisfy the requirements. What apps, tables, forums, screens, columns, views, buttons, functions, flows, plugins, and add-ons and integrations are required. Add in all the data migration and the non-functional requirements like security, performance, usability, storage, operational, maintainability, supportability, and quality criteria. Specify it all in as much detail as possible. And then get it reviewed and signed off by the customer. Who usually doesn't understand what any of it means. 

Finally, lay it all out in a Gantt chart that shows the dependencies, the task-level estimates in 15-minute increments and the resources and the management overheads. The chain of dependencies highlights your critical path and the minimum length of time the project will take. Meanwhile, you count up all the effort by all the different resources and multiply them by the resource costs to figure out how much it's going to cost. 

The result of all of that? Only 75% of projects are delivered within 25% of their original estimates. And those statistics don't include the projects that didn't get approved because their estimates were too high and it probably doesn't include the projects that were approved, but later canceled after the estimates were discovered to be far too low.

Every year, thousands of projects do not get anywhere close to 25% of their original estimates. I'm sure you've read about some of the more spectacular blow-outs in the IT press. 

There are lots of reasons for these blowout estimates:

Parkinson's law: Work expands so as to fill the time available for its completion. 

Hofstadter's law, it always takes longer than [00:10:00] you expect, even when you take into account Hofstadter's Law. 

Berard's law 13: Walking on water and developing software against a written specification are easy, if both are frozen. 

Humphrey's law: the user of the software won't to know what she wants until she sees the software. 

Ziv's law: Requirements will never be completely understood; and 

Wegner's lemme: An interactive system can never be fully specified nor can it ever be fully tested. 

Your project estimates might also have been affected by:

Executive wild dreams: when someone with no experience with business apps or a grasp on the complexity of the requirements decrees that the project must be finished within a fixed budget a very short time from now. 

Competitive shortening: when project team estimates get adjusted without their knowledge, usually by a well-meaning sales team eager to win a competitive project. 

Outside estimators: when the people providing the estimates are not the same as the people who will be doing the work, but the people doing the work are the ones who get blamed for not meeting the estimates; or 

Requirements stuffing: when critical new requirements are added late to jury development, but the original schedule is not allowed to change under any circumstances. 

I think we can all agree that a lot of estimation methods are affected by these phenomena. 

There are two common ways of estimating that I find don't work. Let's take a look in the next lesson.

Estimating time doesn't work. A lot of business applications teams estimate in units of time, hours or days. This is especially true for Microsoft partners. Not because it's the best way to estimate work, but because it's the way they invoice for that work. Whoa, whoa, please don't let [00:12:00] how your accounting department invoices for work drive how your delivery teams estimate that work.

Here are four common problems with estimating work in units of time. 

(1). My unit of time isn't the same as your unit of time. You have estimated it'll take one day to get a user story done, but I reckon it'll take five days. 

You're thinking about the effort involved in building a Power Automate flow, but I'm thinking about building a Logic App. And I'm including the time taken to write the app, write the unit tests, the functional test cases, develop the logic app, test it, get it peer reviewed, deployed into pre-production environment, verify with a product owner and then document. It turns out you've only asked them in the effort to develop the flow. 

But even if our definition of done was the same and we agreed that done needs to include development, testing, verification, deployment, and documentation, your experience with Power Automate might mean that you can get it done in a day. Whereas my experience means it'll take me three days of effort. 

We're both right for ourselves, but our estimates are wrong for our team. Estimating in units of time, even when we have that shared definition of done is tainted by our personal experience and the amount of time it would take us as an individual. Units of time don't work for teams because we don't know who in the team will be doing the work. 

(2). There's no such thing as the average developer. To liberate us from the confines of our personal experience, some teams invent a persona, an average developer, and imagine how long it would take this average developer to do the work.

What happens in our heads is that we estimate how long it would take us to do the work. Then we include a fudge factor, by guessing how much [00:14:00] faster or slower we are compared to the average developer persona. All we've done is take bad guess and make it even worse. 

(3). We'll have to re estimate everything if something changes. Imagine we've estimated all the user stories in our backlog and they include the estimated effort to deploy them into pre-production and run a set of manual tests. Then part way through our project, our investment in dev ops and automated testing begins to pay off and suddenly that development and testing effort is cut in half. Now we'll have to re-estimate the time-based estimates of our backlog all over again, because everything has changed.

The same thing could happen if we add three new people to our team, or lose a senior developer, or are affected by an update that Microsoft releases while we're building our application. 

(4). Time-based estimates don't include waiting time. Have you ever had to wait on a business analyst to clarify a detail with a user? Or wait for a system administrator to create a service account? Or wait for another team to provide the API we need for an integration? Or wait for IT to approve a third-party tool or library? Or wait for architectural approval for a novel design pattern?

There are a thousand reasons why we might have to wait. Waiting time is sometimes a far bigger component of the elapsed time than the active development time. Yet our estimates of how much time it would take to get a story done always focus on the active development time and rarely account for waiting time.

We seem to assume that while we're waiting for somebody else to progress our blocked story, we can just pick up another one. Well that just expands our work in progress and not our real progress and it introduces context switching costs. 

Those are the four reasons why I find estimating in units of time, like hours or days, doesn't work.

Let me know [00:16:00] in the comments below if they're working for you or if you find another reason why estimating in time doesn't work for your team. 

Next up t-shirts.

Estimating t-shirts doesn't work either. If estimating in units like hours or days is too concrete, perhaps we'll do better if we use something more abstract. 

Like t-shirts: extra small, small, medium, large, extra large. 

Or even using animals: mouse, cat, dog, pony, horse. 

But what happens when your project sponsor asks you: how long is it going to take? 

Can you really tell her it'll take three smalls, four mediums, five larges and three extra larges. Or five mice, seven cats, four dogs, five ponies, and four horses?

Seriously, could you do that with a straight face? 

Of course, what ends up happening behind the scenes is that someone transposes the t-shirts, or animals, into numbers so that they can be added together and presented as something that is hopefully far more meaningful and useful to your project sponsor. 

I'd love to see your sales proposal with animals in it though! 

Come on! Let's just use numbers in the first place.

Estimates, forecasts and commitments. Estimates are different from forecasts and commitments. 

We usually get asked to produce estimates at the start of a project. Or before the project even starts. At this point, we know the least about the business goals and the requirements. We don't know for sure what technical solutions we'll be using to meet those requirements. We might not even know who will be on our team. 

I call this the point of peak ignorance. If we estimate at this point, it's just a guess.

In this course, you're going to learn how to provide estimates that are an educated guess that we can build on and expand and adjust as we learn more [00:18:00] and our experience builds. But it's important that your stakeholders understand that estimates are guesses. Guesstimates. 

They're not forecasts.

A forecast is a probabilistic prediction of how much it'll cost and how long it'll take based on empirical data. Once your team has a track record of creating product increments, Vasco Duarte calls them Running-Tested-Stories, then you can make forecasts. 

An estimate is, "Based on our experience of similar projects and our current understanding of your requirements, we estimate it'll cost $2.2 to $2.6 million and take six-and-a-half to eight months to deliver your project based on a team of seven developers." 

A forecast is, "Based on our progress so far, and what we know about the work remaining, we have 80% confidence that will cost 800 to $900,000 and take four or five sprints to finish delivering this release."

A commitment is something different altogether with a much higher confidence. A commitment is, "This release will be done at the end of next sprint. Even if I have to do the data migration myself. Full satisfaction guaranteed, or your money has been wasted!"

I'm not, I'm not a big fan of commitments.

It's vital that when you're being asked "how much and how long?" that you provide an estimate and your stakeholders understand it's your best guest and not a forecast or a commitment. 

This is the last lesson in section one. In section two, Story Points, you'll learn what story points are and how to choose the right story point estimation scale for your project.

I hope you enjoyed that tester of the lessons you'll find inside section one of Estimating Business Applications. You can join the course for free by clicking on the link in the show notes at [00:20:00] https://AmazingApps.Show/127. I'd love to see you in there. Until then, keep sprinting.