Welcome to Estimating Business Apps episode 1. In this episode, I introduce the first section of the Estimating Business Apps course. Join me to learn why:

  • Stakeholders deserve accurate estimates.
  • Estimates are notoriously inaccurate.
  • Estimating in units of time doesn’t work.
  • Estimating in t-shirts doesn’t work either.
  • Estimates are different from forecasts and commitments.

The Estimating Business Apps is a companion podcast to my Estimating Business Apps online video course. You can join the Estimating Business Apps course for free here: https://customery.com/estimating

The first three sections of the online video course are free. By joining the Professional Plan, your support helps me make my training available to as many business apps builders as possible.

Transcript

[00:00:00] Welcome to Estimating Business Apps, episode one.

My name is Neil Benson. I've been building business apps since 2006, using Scrum since 2008, and a Microsoft MVP for business applications since 2010. In this podcast you'll learn how to estimate Power Platform and dynamics 365 applications, so that you can answer your stakeholders two favorite questions: "How long is it going to take?" and "How much is it going to cost?"

I love estimating business apps. And I've developed a method of quickly, accurately and confidently estimating business apps that my teams have used to win over a hundred million dollars of projects.

I share that method in my Estimating Business Apps video course in the Customery Academy. I'm going to share it with you for free in this short podcast series.

This episode includes a welcome session for my online video course, and the first section of the course, which has five lessons: How much and how long. Why estimates are notoriously bad. Estimating and time doesn't work. Estimating and t-shirts doesn't work either. And finally, Estimates, forecasts and commitments.

If you want to not miss the next episode of Estimating Business Apps, make sure you download all the podcast episodes now. They're all available. There's no need to wait. Go and get them all while you can.

Estimating Business Apps, by Neil Benson. Narrated by Neil Benson (that's me!). Copyright 2024 Customery Pty Ltd.

Here's the welcome session from Estimating Business Apps.

Neil Benson: 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 [00:02:00] that your 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 lessons. 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.

The first three sections are available to everyone on the Free plan. The last two sections contain the advanced content and are available on the Professional plan. And there is an offer to upgrade, if you're on the free plan and want to access the advanced content in the last two sections.

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. The software industry is renown for being crap at answering those two questions. [00:04:00] 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, hopefully with the product owner, note our assumptions and creating an estimate. Different team [00:06:00] 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 in as much detail as possible. If you forget something or get something wrong, [00:08:00] 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.

Neil Benson: 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 you expect, even when you take into account Hofstadter's Law.

Berard's law 13: [00:10:00] 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

Neil Benson: 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.

Neil Benson: 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 how your accounting department invoices for work drive how your delivery teams estimate that work.[00:12:00]

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.

Neil Benson: 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 faster or slower we are compared to the average developer persona. All we've done is take bad guess [00:14:00] 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.

Neil Benson: 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 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.

[00:16:00] 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 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 and our experience builds. But it's important that your stakeholders understand that estimates are [00:18:00] 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.

You've been listening to episode one of the Estimating Business Apps podcast, which covered section one of my online video course also called Estimating Business Apps.

In episode two, you're going to learn about story points. Story points are sometimes controversial in the agile community. And while we have a couple of minor shortcomings, [00:20:00] I think there are a great way for Power Platform and Dynamics 365 teams to overcome the limitations of estimating in time or t-shirts.

In episode three, I share the method that my teams have used for the past 10 years to estimate requirements by slicing them into small user stories, setting a standard, choosing a scale, and then finally using either affinity estimation or planning poker to estimate the relative size of all the items in the backlog. Finally, we'll learn how to turn story point sizes into estimated duration.

In episode four, you'll learn how to scale up your estimating technique from estimating individual requirements, to mastering the art of estimating entire applications.

In episode five we wrap up the Estimating Business Apps podcast with the answers to the top 20 questions I get from Power Platform and Dynamics 365 teams about estimating apps. We cover everything from story point objections, to re estimating stories, to handling conflicting estimates within your team.

I hope you enjoyed and learned something from this first episode of the Estimating Business Apps podcast. I wanted to make this content absolutely free for everyone, regardless of whether or not you decide to invest in the Estimating Business Apps video course. If that's something you're interested in, stick around to the last episode of the estimating business apps podcast, and find out how you can get an exclusive discount for the video course.

I'll see you inside episode two, story points.

Until then, keep experimenting.