Welcome to Estimating Business Apps episode 2. In this episode, I introduce the second section of the Estimating Business Apps course.

Join me to learn how:

  • Estimating a requirement is like estimating a running trail.
  • Effort and the three other factors need to be included in your estimate.
  • Your team can choose an estimation scale for your business apps projects.

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

Neil Benson: [00:00:00] Welcome to Estimating Business Apps episode two. In this podcast you'll learn how to quickly, accurately and confidently estimate your Power Platform and Dynamics 365 applications.

In episode two, you'll learn why and how to use story points to estimate the relative size of your Power Platform and Dynamics 365 requirements. This episode is an audio version of section two of my Estimating Business Apps online video course.

Inside you'll learnhow estimating running trails is just like estimating requirements for your business apps. But estimates aren't just about how long something would take or even how much effort something might take, there are factors affecting each estimate that you'll learn about inside. Finally, you'll learn how your team can choose a story point estimation scale to use. If you work for a Microsoft partner, I recommend that all your project teams use the same estimation scale so that you can improve the consistency of your estimates.

I'm publishing all of the episodes of the Estimating Business Apps podcast together. So make sure you download the remaining episodes today. They should be available in the podcast player where you find this episode.

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

Neil Benson: Here's the second section story points from my Estimating Business Apps video course.

Trail running. Hi, I'm Neil Benson from Customery. Welcome back to Estimating Business Applications, section 2.

My wife and I enjoy trail running together. Ten years ago, I was running ultra marathon trails barefoot, but these days she's fitter and faster than me. One of the places we love running is [00:02:00] Mt Coo-tha on the edge of Brisbane.

One of her favorite runs is the Coo-tha Loop via the Powerful Owl trail. When I asked her to estimate how long it would take us to run the trail together, she said it would take about an hour. It took us an hour and a half. What happened?

She's an experienced trail runner and she's an expert on all the trails around Coo-tha. When I asked her to estimate the trail, she just estimated in a unit of time, one hour. Just like a lot of business apps development teams do when asked to estimate the size of their requirements.

Another approach she could have taken is to estimate the difficulty compared to other trails that we've run together.

The Coo-tha Loop via the Powerful Owl is about eight kilometers. We use kilometers as a unit size, but we could just as easily use miles. Natascha runs trails at eight kilometers per hour. So the Powerful Owl Loop normally takes her an hour. I don't, my speed is more like six kilometers an hour, and that's when it's flat.

When we include the 278 meters of elevation to climb, the creeks we had to jump across, and the treacherous condition of some of the trails after the recent rain, it's no wonder it took us an hour and a half.

If Natasha had told me it's an eight with several steep climbs, creeks, and muddy trails, we could have agreed to call it a 13 because of the distance adjusted for all those other factors that make it harder.

The Kokoda trail at Mt Coo-tha is 10 kilometers, but it's got even more elevation to climb, 422 meters. It's a bit longer and significantly steeper than Powerful Owl. If Powerful Owl is a 13. Then the Kokoda trail is a 20.

That's all story points are. A generic unit for estimating the size of a requirement compared to other requirements.

Let's find out [00:04:00] the four factors that make up the size of a requirement.

Factors affecting size. Let's unpack the size of a requirement and the factors that affect that size. Most of what determines the size of a requirement is the amount of effort it will take to turn the requirement into an increment. That is, the amount of work to be done to complete the analysis, design it, build it, test it, deploy it, validate it, document it or whatever you need to do to satisfy your team's definition of done.

Wait a moment. Are you saying that we measure the amount of effort in units of time? Yes, we do. In the same way that what made up most of the size of a trail around Mount Coo-tha is distance. But when we compare two trails, we don't just compare the distances. We factor in the elevation, the hazards, the trail surface, and even today's weather.

When we compare two requirements, we don't just compare the amount of work to be done. We factor in any risks, uncertainty or complexity involved.

Risks could be that the requirement could change because of merger and acquisition activity, changes in regulation or legislation, changes in the competitive landscape, or changes in leadership, or a very common one, our dependency on another team who we rely on to help us get our work done.

Uncertainty could be the volume of exceptions we need to handle in a business process, the volume of data we need to migrate, or the different types of product categories we need to support our application.

Complexity could relate to whether we'll need to build a custom business rules engine or whether we can buy a rules engine application and integrate it, or our inexperience with the new Subscription Billing feature in Dynamics 365 Finance.

If something is going to impede your work, it doesn't really matter whether you call it a risk, [00:06:00] uncertainty, complexity, or a blocker, inhibitor, or obstacle or issue. Whatever you want to call it, you'll need to factor it into your estimate when you compare two requirements.

Imagine that a requirement will take your team a total of 30 hours' effort. The requirement is well-known and understood across the team. You've done similar requirements like this one 10 times before, you've got all the skills needed within the team, and aren't relying on anyone else outside the team. You're pretty confident nothing's going to get in the way. We can call that a 30-point requirement.

Imagine a second requirement that would also take your team a total of 30 hours effort to meet the same definition of done. But the business analyst still needs to check a few details relating to two edge cases. You're not sure whether the integration needs to be real-time or scheduled, and you'll need approval from the integration design board. The product owner needs approval from the owner of the target system and hasn't heard from her in a few weeks. It's potentially the same amount of effort as the first requirement, but you'd be wise to account for the potential risks, uncertainty and complexity involved in the second requirement. Let's call it a 50-point requirement.

Story points are estimates of effort. The effort involved in satisfying a requirement isn't measured in units of time, because we don't know who will be doing the work and how fast those people can work, and we're not sure what potential impediments they'll face.

Instead, we measure the size of requirements in story points, which are risk-adjusted units of effort.

Estimation scales. When your team decides to estimate in story points, you'll need to decide on an estimation scale.

I don't recommend choosing a scale, like one to one hundred, and having every number in the scale available for estimating the size of requirements. There are two reasons for this; two laws actually.

The first is Hick's [00:08:00] law: the more choices you have, the longer it'll take to choose. We've already learned that estimating is an essential activity, but we want to minimize the amount of time it takes to produce useful estimates. Natascha, my trail running wife used to work at GlaxoSmithKline. Every time they launched a new toothpaste, they tried to remove an old one from the shelves because consumer feedback told them that no one enjoyed spending more time choosing toothpaste. No kidding, right?

Don't give your teams too many options in your estimation scale.

The second is Weber's law of Just Noticeable Differences, coined to by psycho-physicist, Gustav Fechner. Fechner assert asserted that the minimum reliable detectable difference between two weights is about 5%. If we apply that to estimation, it suggests there'll be have a hard time estimating whether a requirement is a 50 point requirement or a 51 point requirement, because the difference between those two numbers is only 2%.

Taking Hick's law and Weber's law into account, there are two popular estimating scales for development teams.

They are the Powers of Two scale and a modified Fibonacci scale.

The Powers of Two scale uses a simple doubling of numbers starting with one. It goes 1, 2, 4, 8, 16, 32, 64, 128, 256, 512 and 1024.

You're welcome to use the Powers of Two scale but I must admit that all my teams, since I started using story point estimation, have all used a modified Fibonacci scale. I don't think one scale is necessarily better than the other and you could be successful using either scale.

What's the modified Fibonacci scale?

Let me share with you the scale that my teams use, and then the reasons why we use this scale. It goes [00:10:00] 1, 2, 3, 5, 8, then 13, 20, 40, 60 and 100, then 200, 300, 500, 800 and 1,300.

The numbers 13 and up, I use for estimating features, epics and projects. I cover those in section 4. I use the numbers 1, 2, 3, 5, and 8 for estimating requirements, and I'm going to show you how to do that in section 3.

By the way, a true Fibonacci scale goes 13, 21, 34, 55, 69 and so on. But I find that my stakeholders assume a false level of precision with these numbers. So I use rounded numbers 20, 40, 60, and 100 instead. And they're also easier to add up quickly.

We're going to focus on the small numbers at the start of the scale 1, 2, 3, 5, and 8. Join me in section 3 as we learn how to use this scale when estimating requirements.

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

In episode three, you'll learn how to estimate requirements by slicing them down into small user stories, setting a standard user story, and then using either affinity estimation or planning poker to estimate the relative size of all of the requirements in your backlog. And you'll learn how to turn story point sizes into estimated durations so that you can answer the question, "How long is it going to take?"

In episode four, you'll learn how to power up your estimates from individual requirements to entire applications. This episode corresponds to section four of my Estimating Business Apps course, which is part of the Professional Plan.

In episode five, we'll wrap up the Estimating Business Apps podcast with the answers to the top 20 questions I get from students about estimating Power Platform and Dynamics 365 apps. We'll cover things like, [00:12:00] equivalency between story points and hours or days, changing your estimate of velocity, and becoming quicker at estimating business apps as a team.

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

Neil Benson: I'll see you in episode three, How to estimate requirements.

Neil Benson: Until then, keep experimenting.