Using Story Points to Estimate Power Platform and Dynamics 365 Apps

Neil Benson: [00:00:00] Welcome to Amazing Applications episode 128. G'day, I'm Neil Benson from Customery. Our mission is to help Microsoft customers and partners build amazing, agile Dynamics 365 and Power Platform applications that everyone will love. 

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

If you've been listening to the show for a while, you might remember that my house was inundated in the floods affecting eastern Australia earlier this year. The good news is that my family is back in the house, but my studio isn't gonna be ready for me to move back in for another month or two. So I'm still in my temporary office with my temporary podcast recording gear.

I'm planning lots more interviews and original solo content once I'm back in. But thanks for your patience until then. I appreciate you for bearing with me and this subpar audio recently. 

If you caught the last [00:01:00] episode, #127, it was an audio sneak peak of the first section 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 to business development, through presales and delivery. It'll give them 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 that your customer is looking for.

If you work for a Microsoft customer, you probably get the same questions from your project sponsors and stakeholders, whether you have a Microsoft partner helping you or not. I hope you'll find the course useful as well. 

This episode is a sneak peak of section 2: Story Points. There are three video lessons in the section and I've rolled them all into one podcast episode for you.

If you want to take the online course with the videos and quizzes, [00:02:00] you can join for free by following the link in the show notes at https://AmazingApps.Show/128. I look forward to welcoming you into the course. Until then here's section 2: Story Points.

 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 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 [00:03:00] 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, [00:04:00] 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 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 [00:05:00] 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 [00:06:00] 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, 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, [00:07:00] 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 [00:08:00] 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 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 [00:09:00] 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, [00:10:00] 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 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 [00:11:00] 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. 

That was an audio sample of the lessons in my Estimating Business Applications online course. You can join the course to get the video lessons and quizzes for free at https://AmazingApps.Show/128. Until then keep sprinting.[00:12:00]