In this episode, we’re going to be talking about how we estimate business applications. When I talk about estimation, I mean how long is it going to take and how much is it going to cost.

Some people call it forecasting, and I’m fine with that. For our purposes, estimation and forecasting are the same activities and result in the same thing: a shared understanding of what we’re going to build and how long it’s going to take.

Why do we estimate?

Why do we estimate? Let’s start there.

I’m working with a financial services provider in Sydney at the moment. They audit self-managed superannuation funds, which is a type of retirement account in Australia for high-net-worth individuals.

They’ve built a software application for auditors to manage a fund’s annual audit process, and they want to build another new application for accountants to manage the tax returns and financial statement process for the funds. The two processes are similar, but for independence purposes are usually prepared by separate accounting and audit firms.

Within my client’s board of directors, there’s no shared understanding of how long it should take to build this new application. Will it take 3 months to copy the audit application and make a few changes, or it is a 12-month project to build a completely new application from the ground up?

I thought it would be useful to walk you through the estimation process that I use with my Dynamics 365 and Power Platform clients to help you think through and maybe improve your own estimation process.

We don’t always need to estimate our business apps, but when we do there are usually two reasons: time and money.

Time

Our users want to know when they’ll be able to use the application. If you’re releasing incrementally, they want to know when each release will be deployed and when their requested features are going to be available.

All sorts of other stakeholder groups also care about how long it’ll take to build our application.

Testers want to know when to run user acceptance testing or penetration testing.

Change managers want to know when to run communications and engagement programs.

Trainers want to know when they can train. 

IT departments want to know when they’ll need to schedule a release.

If your application is going to be used externally, marketers and customer success managers want to know when to set their customers’ expectations regarding your new application.

Dependent application teams want to know when you will unblock their dependencies.

And of course, project managers want to know what expectations to set with stakeholders all the way up to the board of directors, maybe even shareholders.

How long it’s going to take matters.

Money

And the reason that it matters is: money. 

The longer it takes to build your application, the more it costs.

I’ve never worked on a project where that isn’t true.

And because of that correlation between how long it’s going to take and how much it’s going to cost, once we estimate the effort, we can forecast the cost.

Do we need to estimate effort?

I mentioned earlier that we don’t always need to estimate the effort involved in building our applications, but those occasions are rare.

If you’re building a personal application or maybe a simple application for a small team, you might not need to estimate the effort involved. Maybe you’re doing it to enhance your skills, as a hobby or as a labour of love. You probably wouldn’t estimate the effort in these situations.

If you’re building a more sophisticated business application, the only other occasion I’ve encountered a development team that didn’t need to estimate their effort was because they split all their requirements into chunks that all took the same amount of effort. Let’s say you have 100 requirements. Your metrics show that each requirement takes one person about one week to get done. So it’ll take 100 weeks for one person to get all the requirements done, or four months if you had a team of 6 application makers. As long as you keep splitting or joining all your requirements so that they are all about the same size then you can forecast the time it’ll take and how much it’ll cost without estimation. 

But this scenario is rare. Most of us work with requirements that come in a wide range of sizes so we’ll need to put some effort into estimating the size of each of them.

Accuracy and precision

Accuracy and precision are two related concepts we encounter when we are estimating.

Accuracy refers to the correctness of our estimates. If we estimated that it would take between 4 and 5 months to build the next version of our application, our estimate was right if it actually took more than 4 and less than 5 months. If it took 3 months, then our estimate was inaccurate. If it took 5½ months then our estimate was inaccurate. 

I think being accurate is important. My team’s like to get it right. Our stakeholders rely on us to be right.

Precision refers to the exactness of our estimates. If we estimated that it would take exactly 115 days to build the next version of our application, our estimate would be wrong if it took 95 days, 105 days, or 125 days. We would have missed our precise release date.

For this reason, I don’t think being precise is that important. It will lead your estimates to be wrong almost all the time. 

If you’re working with a new application, or a new team, or a new client there are so many variables affect your estimates that it’s impossible to be precise. 

Sometimes stakeholders want us to be precise. If we give them a range, for example between 4 and 5 months, it’s not uncommon for them to selectively hear what you just said and tell everyone it’ll take 4 months. They’ve just applied a level of precision to your estimate that is likely to be wrong.

The less we know, the harder it is to be accurate. We have to work with ranges. We know barely anything at the outset of a project to build a new application so our estimates might fall within a wide range that gets narrower over time as we learn more.

It’s up to us as Microsoft Business Applications professionals to help our stakeholders understand the difference between accuracy and precision, and to provide them with accurate estimates, not necessarily precise estimates. Initially, our accurate estimates will fall within a wide range because of all the of uncertainty at the start of a project, so we need to update our stakeholders with better estimates when we can.

When do we estimate?

If we follow that logic, it becomes clear that estimation isn’t a one-off activity. We need to update our estimates.

I recommend creating an initial estimate before we start building the application, and again every 3 or 6 months, usually after we deploy a major update.

Before building the application

The most common time to estimate, of course, is before we start building the application. Usually, a client will have created a high-level estimate of effort and costs to support their business case. The estimated costs have to be significantly lower than the returns otherwise the return-on-investment doesn’t stack up and the business case for the application will be rejected.

But at this stage, we often don’t know what application vendor will be selected, who will be implementing it or even what features will be in each release. The business case estimate is a coarse-grained estimate that will usually get refined again before we start building the application.

Once we know we’re implementing Dynamics 365 or Power Apps or Power BI, and we know the team or the Microsoft partner, and we know at a high-level the features that will be in each release then we can refine that business case estimate in a roadmap or project plan that gets approved for go. Now we kick-off our project and start building our application sprint by sprint.

The estimate in the approved project plan had to make some forecasts about the size of each requirement and how long it’ll take to build each one. We’ve got no experience working together, and we might have a lot to learn about our user’s industry, their organisation and its business processes. 

So our accuracy at this stage is usually still a wide range.

While building the application

After a few months, our implementation team has built some features. Now we have some historical data that might help us better estimate the size of the remaining requirements and forecast how long it’ll take to build each one. We’ve got experience working together. Hopefully, we’ve gone through Tuckman’s four stages of teamwork -- forming, storming, norming, and performing -- and we’re now a high-performing application development team.

Now we can revise our estimates for future releases and provide our stakeholders with update estimates that are more accurate than before.

We can repeat this exercise after every release or every three or six months as requirements change, as our understanding improves and we have more historical data that helps us provide more accurate estimates.

OK. We’ve talked about why we estimate and when we estimate, let’s start talking about how to estimate the effort and cost of our business applications. Starting with choosing our estimation units.

What are we estimating?

Are estimates really about effort or something else? 

Effort

Are we estimating the effort that it would take to get a requirement done? 

We could. We could estimate that it’ll take 2 days of effort to achieve a requirement, for example. 

But there are a couple of problems we run into if we estimate the pure effort involved.

Firstly, is it the effort you would need to exert to get the requirement done? Or me? Or Scott Durrow? Or Shane Young? 

Because depending on what’s needed to meet the requirement will take people with different skills and experience, different levels of effort.

And besides, building business apps is a team sport, which means that it will likely take the effort of more than one person to get the requirement to done.

How do we factor that in everyone’s different abilities if we don’t know who is going to be working on any given requirement in the future?

What’s more: what does done even mean? Does done mean the feature has unit tests? Does it have to be system tested? Peer reviewed? Documented? Acceptance tested? Deployed into staging or production?

Our definition of done will likely change as we build our application. Won’t it take more effort to meet requirements that have more stringent criteria in the definition of done? 

The third issue with measuring effort is that we might be asked to measure the effort it takes to achieve something we’ve never done before.

What about estimating complexity then?

Complexity

Estimating complexity is better than estimating effort. Complexity allows us to take the measure of effort and adjust it based on risk or uncertainty.

If we have never integrated inventory from Dynamics 365 Business Central into Field Service before, we might want to adjust our estimate to factor in the risk of learning how to tackle a novel integration.

If we’re going to be dependent on a third-party to implement Adobe Campaign so that we can integrate with it for managing customer subscriptions in Dynamics 365 Sales, then we might want to factor in the extra overhead of coordinating with another team.

Whereas, if we think we’ll need to build a custom Power BI dashboard and embed it inside a canvas app and that’s something our team has done dozens of times before then our estimate of complexity will be the level of effort required without adjusting for any special risks because of our familiarity with the pattern for embedded Power BI dashboards.

There’s just a couple of examples of how we can take effort and adjust it for risk to arrive at the estimated complexity when we need to.

Relative Complexity

To solve the other challenges of estimating effort (namely: whose effort are we measuring and how do we know what done looks like), we’re going to use something called relative complexity.

When we estimate in relative complexity, we take two requirements and compare their relative size. Later, we estimate our speed to see how long it’ll take to get each requirement done. 

Mike Cohn calls this: estimate size, derive duration.

My wife and I love trail running. Last year Natascha ran a 50km race through the hills around Brisbane, and regularly runs 15km mountains trails after she drops the kids off at daycare.

I used to run even further, but these days 5k or 10k along the river is more my style. I run at a faster pace than Natascha, but she’s got greater stamina.

We have a couple of trails that we have run together. So when I ask her how much effort it takes to run a new trail, like Powerful Owl at Mt Coo-tha, she’ll tell me it’s twice as hard as the Kokoda Trail.

She’s comparing the relative complexity of a new trail with a known trail. It doesn’t matter if she runs them at a 9mins/km pace and I run them at 7min/km. Powerful Owl will likely take me twice as long as Kokoda.

Using relative complexity, we can compare the effort of all the trails around Mt Coo-tha to the known complexity of Kokoda. There’s a risk that the repairs on Bellbird Trail aren’t finished yet and the diversion is still in place, so even though it’s usually the same effort as Kokoda, we’ll adjust the estimated complexity upwards to account for the risk of a detour.

I recommend to my teams that we estimate the relative size of our requirements, which is a forecast of the effort it’ll take to get the requirement done, adjusted for the complexity or risk. And it compares every requirement in our backlog to the complexity of a baseline requirement. 

Before we discuss how we estimate our velocity, which is the rate at which we can get requirements done, let’s discuss the two most common estimation units plus a couple of others.

Choosing our estimation units

Choosing your estimation units at the beginning of a project is important. Because it’s really hard to switch later.

If you’re a Microsoft customer, you’ll want to standardise across all the projects in your organisation so that they use a common unit every time.

It’s the same if you are a Microsoft partner, you’ll want to use the same units of estimation across all the project you work on. Occasionally, you might have to deviate from your standards when required by a customer who uses a different unit. 

Ideal time

When we estimate the size of a requirement in ideal time, we’re saying here’s how long it would take us to get this requirement done if:

1.       We got to focus on just this requirement and nothing else.

2.       There were no distractions or interruptions.

3.       Everything goes well and we don’t find any missing dependencies or anything else missing from the requirement.

This is how long it would take in an ideal world.

But real-life isn’t ideal, and so the actual time taken is always, always longer than ideal time.

Just like in sports, the actual time taken to play a game of rugby is longer than 80 minutes, to play a game of soccer takes longer than 90 minutes, to play a game of NBA basketball is much longer than 48 minutes, and playing a game of American football takes about three or four times longer than the 60 minutes of game time. 

Those games have lots of interruptions and stoppages that means that a minute of game time takes longer than an actual minute.

It’s the same with software development. 

An ideal hour or day used in our estimates takes longer than an actual hour or day.

Imagine your boss asks you how long it will take you to read the latest Dynamics 365 and Power Platform release notes. There are about 900 pages which you can read at a rate of about 60 pages per hour. You tell your boss it’ll take you 15 hours.

“Great, I’ll check back in with you tomorrow for a summary”, says your boss. 

But you never meant to imply that you were going to drop everything else and start reading the release notes continuously for the next 15 hours.

You’ve got other work to do today. A family to home to this evening. You had intended to sleep tonight. 

While you were planning to spend two hours a day reading the release notes over the next couple of weeks, your boss took your ideal time estimate and ran with it as an elapsed time estimate.

This confusion something I’ve seen on projects where estimates are provided in ideal time, especially for epic-sized requirements where the estimate might be forecast using big numbers. 

Story points

Story points are an alternative way of providing an estimate for the size of a requirement. Unlike ideal time, story points are abstract. They allow us to compare the relative size of two requirements, but on their own, we don’t know how long it will actually take in elapsed time to get any of the requirements done.

If the first requirement is estimated at 1 story point, the second at 2 and the third at 3, then it should follow that it’ll take the same amount of effort to complete the first two requirements as it will to complete the third. Because 1+2 is equal to 5. 

All the requirements with the same story point estimates should take about the same amount of time to get done.

There shouldn’t be any funny maths when you’re using story points. The basic laws of arithmetic all hold.

Unlike ideal time, there isn’t any confusion about how long it’ll take to complete a feature, a release or an application when we provide estimates in story points. If you tell your stakeholders that the next release is estimated at 208 story points, they don’t know how to convert that into elapsed time.

If you told them the next release was 208 ideal hours, there is a possibility their hearing would be impaired momentarily and they’d assume you meant 208 elapsed hours and assume you’d be done in about a month.

We’ll discuss the advantages of ideal time and story points in just a moment, but first, let me describe one more unit of measure.

Other units

The other unit of measure used by some teams for estimates is t-shirt sizes. 

We can estimate the relative size of different requirements using the same sizes that t-shirts come in, such as extra-small, small, medium, large, extra-large, and extra-extra-large. 

The benefit of t-shirt sizing is that it is usually easy to explain and for developers and stakeholders to grasp.

It’s quick for developers to estimate the relative sizes of requirements in t-shirts.

The big downside is that the basic laws of arithmetic don’t apply to t-shirts. You can’t add them together.

If you say this release is four small, three mediums, two larges and an extra-large there’s no way anyone can understand whether that’s more work than two extra-larges or how long it’ll take to get all the requirements done.

Some teams convert t-shirt sizes into numbers so that they can add them up. But if you’re going to do that, you might as well just start with numbers in the first place.

Those numbers are called story points.

I don’t recommend estimating in t-shirt sizes.

But before I share my preference with you, let’s look at the advantages of ideal time and story points, and then I’ll share with you the reasons behind my recommended unit of estimation.

Advantages of ideal time

Estimating in ideal time has a couple of advantages.

Everyone can grasp the concept of estimating the size of our requirements using time. Time is a concept that we learn at a young age so it doesn’t take any explanation when we say this requirement will take two days. 

Developers get it. Our business stakeholders get it.

There’s no learning curve or explanation required with estimating in time.

The biggest disadvantage of ideal time is explaining that ideal time is not the same as elapsed time.

Sure, I can read the Dynamics 365 and Power Platform release notes in about 15 hours, but it’s going to take me two weeks because I only have the capacity to read for two hours every day.

I need to explain to my boss the relationship between 15 hours of ideal time and two weeks of elapsed time. But there’s still a good chance he’ll forget and tell his boss that it takes 15 hours to read the release notes.

This drawback can be turned into an advantage though. Tomorrow, when my boss asks me for a summary of the release notes and I’m only two hours into the job then we can confront the reasons why it takes two weeks to achieve 15 hours of work. The interruptions from people on other projects, the emails, the team meetings, the compulsory health and safety training, the fire drill, the triplicate timesheets and compiling status reports that no one reads.

Uncovering all of that unproductive time can lead to a healthy discussion about focus, openness, and transparency. That’s if I still have a job after failing to summarise the release notes the day after I said it would take 15 hours.

Stakeholders have a habit of equating ideal time with elapsed time, but if you can help them break that habit then ideal time is a fine unit of measure for estimating requirements.

Advantages of story points

One of the advantages of estimating in story points is that it’s impossible for our stakeholders to equate story points with elapsed time because the units sound different and are different.

Instead of saying that it would take me about 15 hours to read the release notes, imagine I had said it’s a 3 story point requirement. My boss would have asked how long it’s going to take, and I’d explain that I’ve got capacity for 3 points of work over the next two weeks so that’s how long it would take.

Remember, one of our goals is to estimate the size and derive duration.

We derive the duration by dividing the amount of work by our velocity. Velocity is the amount of work I expect to be able to get done within an agreed timeframe. It’s the rate of getting things done.

Whether we estimate in ideal time or story points, we need to divide the total estimate of work by the estimated velocity. 

If you remember your high school physics lessons time = distance/velocity. It’s exactly the same: story points are the distance we want to travel, velocity is the rate at which we can get story points done and time is the elapsed time we can derive from the other two.

You might need to spend a little time explaining the concepts and the calculations to your developers and stakeholders. But I don’t think it’s a difficult concept, and while I’ve met lots of stakeholders who think we should be able to go faster, that’s just proof that they’ve well and truly grasped the concept.

Story points remind us that we’re measuring the relative size of requirements, not how long it will take. 

Sometimes, teams estimating in ideal time will forget and someone will provide an estimate based on how it would actually take to get a requirement done. In the middle of a long estimation workshop, someone might say, “It’ll take me 5 hours to build a Logic App for that.” And the estimate will be recorded as a 5. But the developer has estimated how long it will take him to do the work, instead of comparing its relative size to other requirements and estimating in ideal time. This probably won’t happen often but can happen often enough to throw out your estimates. It doesn’t happen when you’re using story points.

Another advantage of story points is that we can estimate all the requirements collaboratively as a team without knowing who is going to be working on the requirement. 

My wife runs the trails around Mt Coo-tha a lot more than me and has better stamina. I’m slightly faster. But we can compare any of the trails to the Kokoda Trail even though we complete the Kokoda Trail at different times.

Estimating in story points is the same. We can estimate all the requirements in relative story points without knowing whether it’s an amazing developer like Scott Durrow or Daryl LaBar who’s going to be working on it or a terrible developer like Gus Gonzalez who’ll pick it up. We simply estimate the relative size in story points. Our team’s velocity will take care of the differences between individual developers.

So which estimating unit to I recommend?

My recommended estimation units

You might already have a preference between ideal time and story points. Both can and do work for different teams. I don’t think t-shirt sizes are practical, but you’re welcome to use either ideal time or story points for estimating your business applications.

If I have a choice, I use story points.

Story points can take more explanation upfront compared to ideal time, but the benefits are long-term.

If you’re going to use ideal time, remember to keep the estimates relative and not absolute. You might also want to consider dropping the words ‘hours’ or ‘days’ so that ideal time doesn’t get confused with calendar time.

You could use something abstract like “units of work”, or something more tangible like Tim-Tams, the famous Australia chocolate biscuit because the average Aussie developer consumes two Tim-Tams per day.

But if you’re going to go to that trouble, you might as well just call them story points.