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

Join me to learn how to:

  • Scale up from estimating requirements to estimating complex business applications.
  • Determine your team’s initial velocity even if you’ve never worked together before.
  • Derive the cost of your project based on the run rate of your team.
  • Visualise your estimates using scaled backlogs, user story maps and release burndown charts.
  • Use your estimates in compelling sales proposals.
  • Handle fixed-price, fixed-date or fixed-scope 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.


[00:00:00] Welcome to Estimating Business Apps episode four.

This is a podcast mini series in which you'll learn how to quickly, accurately and confidently estimate your Power Platform and Dynamics 365 applications.

In this episode, you'll learn how to level up my requirements estimation methods that you learned in episode three to be able to estimate epics and entire applications, or even a portfolio of applications.

Inside episode four, you'll learn:

How to estimate the size of complex Power Platform and Dynamics 365 apps using story point estimation.

You'll get to be a fly on the wall of an estimation workshop and listen in as my team estimates, a business application. This is one of the most fun course lessons I've ever created, and I really hope you enjoy it too.

You'll learn how your team can estimate their velocity, even if they've got no previous experience working together.

You'll learn how to derive the estimated size of the application and turn that into an estimated cost to build it, a skill that's vital for business cases and proposals.

There's two techniques I use for visualizing estimates. Honestly, this one is better inside the video course because you know, well, it's a visual medium.

You'll also learn how I use estimates and my sales proposals.

Finally, you'll learn how to use my agile story point estimation method even when you need to estimate projects that are fixed-price, fixed-scope, fixed-date or fixed everything.

In the next episode, episode five, it's going to be the last in the special mini series. And it should be available wherever you'd downloaded this episode.

Estimating Business Apps. by Neil Benson. Narrated by me, Neil Benson. Copyright 2024 Customery Pty. Ltd.

Here's section four, How to estimate applications, from Estimating Business Apps.

[00:02:00] Welcome back to Estimating Business Applications. My name is Neil Benson, and I appreciate you joining me in this advanced section of the course. Our goal is to ensure that by the end of these sections you, have leveled up your team's ability to quickly, accurately and confidently estimate how long it'll take and how much it'll cost to build the Dynamics 365 and Power Platform business applications your stakeholders will love.

In the last lesson, I described how my teams use story point estimation to estimate user stories. In this lesson, we're gonna scale up that approach and I'll show you how my teams estimate entire projects. If you're involved in pre-sales work, you're gonna be asked at some point, either by your perspective customer or by your sales team how much is this project going to cost and how long is it going to take?

Or if you work for a Microsoft customer you might be asked the same questions by your stakeholders who are trying to determine if a business challenge can be cost effectively solved with a Microsoft business application.

Here's my method for estimating entire projects to build a Dynamics 365 or Power Platform application.

First, we agree the high-level product backlog for the application using epic- or feature-sized user stories and backlog items. Epics or features, are user stories too big to implement by a team in a single sprint.

In Azure DevOps, epics are refined into features and features are refined into user stories. In JIRA, initiatives are refined into epics and epics are refined into stories. JIRA doesn't have features as a backlog item type.

In any case, whether you call them features or epics or something else, the important thing is that you don't want to work at the user story level. User stories should be [00:04:00] small enough so that you can turn lots of user stories into increments within one sprint. If you try to refine all of your requirements into user stories at the start of a project, you'll get crushed under the heavyweight of hundreds, or more likely thousands, of little user stories.

Zoom out a level and estimate at the feature or epic level. My teams aim to have between 10 and 100 feature-sized items in the product backlog at the start of the project. I find that this is a reasonable number of items for a team to estimate in one or two workshops.

I like to visualize the product backlog as a user story map for the estimation workshops. And we'll look at user story maps later in this section.

The estimation scale that we use with estimating the features or epics for projects is different to the estimation scale that we use when we're estimating user stories.

When we're estimating user stories, I like to use the Fibonacci scale: 1, 2, 3, 5, and 8.

When I'm estimating feature-sized user stories, I like to use this modified Fibonacci scale: 13, 20, 40, 60, and 100.

And if we're estimating epics for huge, complex applications or a portfolio of small applications, I might even use a scale with even bigger numbers: 100, 200, 300, 500 and 800.

Next, I'll gather the team. We haven't started the project yet, so there isn't a confirmed project team.

The first role we need on the team is a proxy product owner. Somebody to represent the requirements of the applications' stakeholders. I'll use the opportunity's pre-sales consultant to stand in for the customer, if the customer isn't available for an estimating workshop.

If you're working for a Microsoft customer, you should have your project sponsor, a [00:06:00] line of business manager or a business analyst available. Whoever knows the requirements best at this point.

The proxy product owner is there to help answer any questions that come up during the estimation workshop. We need them to answer our questions and validate or invalidate our assumptions about the requirements.

As a facilitator, I want to watch out for the times when a product owner wants to frequently dispute or disagree with the team's estimates. Sometimes there are valid reasons why a product owner anticipates a requirement to be simple. Whereas the team thinks it's complex, and that can be a conversation worth having occasionally, but this type of discussion should be an exception and not the norm.

Your proxy product owner can be supported by a few subject matter experts, if they find SME input helpful. For example, if you're building a complex app to replace an existing application, it might be helpful to have somebody from I.T. who knows the existing application supporting the proxy product owner representing the rest of the stakeholders. But we're not diving deep into the requirements or drilling into the details. We don't need a representative for every stakeholder group involved.

I'll invite a few developers to join. I'm defining "developer" here the same way we do in Scrum. It's anyone who will be helping to build the application, not just as programmers, but as architects, analysts, user interface designers, integration developers, app makers, testers, and so on.

I like to have developers with different specialist skills involved in the estimation. The more perspectives we have, then the more robust our estimates will be.

I also want to have a blend of experienced and new developers so that everyone in my practice can learn how we estimate. They get to see how the sausages are made.

I like to have at least three developers involved and no more than seven. You're welcome to experiment with different numbers of developers in your [00:08:00] estimation sessions.

Then we use affinity estimation or planning poker to estimate all the items in the backlog.

Join me in the next video, as we sit in on one of my team's estimation workshops.

Project Estimation Workshop. In this lesson we're gonna watch as one of my teams estimates a new project to deploy Dynamics 365 Customer Service for a government agency responsible for workforce skills and employment.

Let's look at the application's product backlog first. This is the product backlog represented as a user story map in a visualization tool called StoriesOnBoard.

The blue and yellow cards can be used to represent business process activities and steps. I often use them to represent epics and features. Under the yellow cards, you'll see the requirements written on white cards. I write short titles usually in a verb-noun format, like 'Update Accounts', rather than a complete user story description because user story is written in that popular format take just take far too long to read.

The product owner has already prioritized the cards and split them into three releases. We're replacing a legacy system and we need to meet a lot of existing functionality before we can replace that legacy system with Dynamics 365. So that means our first release is gonna be a big one, and most of the cards have been assigned to release one.

When we open a card, it has a short description to remind us about any talking points important to remember while estimating it. None of the requirements have any acceptance criteria or anything close to that, at this stage.

When we're estimating projects, we have to rely on the team's experience estimating similar requirements for similar customers.

Speaking of the team, let's meet them.

I’m Clark, I’m going to be acting as the facilitator for the estimation workshop, and if we win the project, hopefully I’ll get a chance to work with the team as scrum master.

[00:10:00] Hi, I’m Diana. I’m going to be acting as the product owner because, unfortunately, our prospective customer can’t join us for this workshop. I’m the pre-sales consultant from our business development team that’s been working with the customer over the past couple of weeks. I’m not an expert in their requirements, but I’m as good as we’ve got for now.

Hi everyone, I’m Peter. I’m a developer in the Power Apps team. I love extending Power Apps with Power Fx, Power Automate, Dataflows and even some Azure services when needed.

I’m Robin. I’m new to the team and just so excited to be here. I left school a few months ago and I’ve just passed my PL-900 exam last week. This is my first project, and I’m really excited to be working with everyone here. Especially you Bruce.

Um. I’m Bruce. I’m the head of quality assurance. I am the expert at finding bugs. You better believe it when I report a bug in your application. I expect you to drop everything and fix it immediately.

Hey y’all, I’m Selina. I’m an app maker and love building canvas and model-driven apps on Dataverse. I’m also the person most likely to report Bruce to HR if he mistakenly thinks he finds a bug in my app ever again.

I’m Barbara. Hello. I’m a solution architect and I’ve been designing and building Power Apps forever. I started working with Dynamics CRM since before most of you were born.

At the start of the estimation workshop, Diana, our proxy product owner, provides the team with a briefing about the customer, their organization, their existing application, and other systems it's integrated with. Let's join them again as they estimate the first card on the story map.

Let’s start with Create New Contacts. Diana, can you tell us more about this one? What do they mean by creating contacts in New Skills CRM or Delta?

Thanks Clark. The customer needs to be able to create new contact records in Dynamics 3 6 5 and have that contact sync to their Delta application. And it needs to work the other way too. Contacts created in Delta need to sync to Dynamics 3 6 5 as well.

Diana, does the sync need to be in real-time or is an overnight batch sufficient?

[00:12:00] They create orders in Delta, so let’s assume they need the sync to happen near real-time otherwise users wouldn’t be able to create an order until the next day.

Barbara, I think we’ll probably have a plugin that fires when a contact is created and let’s assume there’s a web API available for Delta?

That makes sense, Peter. We’ll also have to assume that Delta can trigger a call to the Dataverse API and create a record in our contact table too.

Are there any special security requirements related to contact creation?

We’ve got another card in the backlog to deal with security role configuration. Let’s assume there is no special security requirements related to this card for the moment.

Is there anything else we need to know?

I’d love to know how many custom columns they need and how their forms and views need to look, but let’s suppose they have the typical requirements we’ve seen in similar projects before.

Is everyone ready to estimate?

I am! I’m so excited. This is my first time estimating anything ever.

OK. Reveal your estimates please.

Bruce, you and Robin had 13. So did you Barbara. Selina, you had an 8, which is our lowest estimate. Peter, yours was 20, which is our highest.

Yeah, I estimated 20 points because this requirement felt to me just like our standard 20-point feature. We’re using a system table that we’ve had to customise a thousand times before, probably adding a few custom columns and laying out the forms and views. There’s a small amount of custom development to integrate with Delta using a plugin. So, it felt like a 20 to me.

I forgot about the plugin development, so my 8 is too low.

Right everyone, let’s play again.

OK, reveal your estimates please.

Selina, you’ve come up to a 13 and everyone else has estimated, 20, this time round.

20 it is! I’m happy to come up to that and move on to the next card.

The team works their way across the board estimating all the cards, taking a couple of moments on each one to discuss and document their assumptions and record their estimate.

We’re almost finished. The last card is just called Data [00:14:00] Migration.

Yeah, I’m sorry about this one. We just don’t have a lot of detail from the customer yet about what their data migration requirements might be.

I thought I saw a table somewhere with some record counts from their current CRM system. Here they are. Two million cases and contacts, three hundred and ten thousand accounts, four million activities and three point eight million documents.

Wow. That’s a lot more than I expected. The documents we’ve dealt with in a separate story. They’ll be migrated to SharePoint. Diana, do you know if they want all those records migrated or are they going to just migrate recent records and archive the rest?

Sorry team. We haven’t had a chance to discuss their data migration needs at all yet. But they’ve mentioned it, so I included a requirement for it.

Team, let’s not spend a lot of time estimating this one. I suggest we give this one a 100-story point estimate to indicate that it’s a lot of effort and even more uncertainty. We can discuss it with them when we review our proposal.

That seems like a fair call. I’ll see if I can get any more details before then, but let’s stick 100 on it and call it done.

Alright everyone. We’re done. We’ve estimated 76 items in release 1, which has a total of 826 story points. And 16 items in release 2, which has a total of 226 story points. Release 3, for replacing their document generation system, is too vague to be able to estimate at this point.

How does everyone feel about the project? It’s just over one thousand story points.

One thousand and fifty two, actually.

I'm glad you're specific Robin. Perhaps there's a career for you in quality assurance

unlike the rest of these folks.

Thank you Robin, and Bruce. How does everyone feel?


Seems fair.

A thousand feels about right.

I'm not too unhappy with one thousand and fifty two, actually.

All right. Thanks everyone. I’ll take this back to the sales team for our proposal and let you know how we get on. I really appreciate the effort. Thanks again team.

That's a quick example of a scrum team estimating the size of a project using story point estimation. It's based on a real life example from one of my teams who [00:16:00] recently estimated a very similar project and actually went on to be awarded that project. So I hope you find that useful.

In the next lesson, we're going to look at how to estimate the team's initial velocity.

Estimating initial velocity. In section three, we learned how a business apps team can predict its velocity. Velocity for an agile team is how much work we get done within a sprint, Usually measured as story points per sprint. When we're working with small user stories, I recommended selecting the first 10 user stories in your backlog and playing fist of five until your team is confident about how many of those stories they could deliver in one sprint.

In our example, the team all showed four fingers outta five when the estimate was that they could complete the first nine stories, totalling 25 points in the first sprint. Their forecast velocity is 25 points per sprint. In this lesson, I'll expand on that method for predicting the Scrum team's velocity when we're estimating entire projects.

Over time when your Power Platform, or Dynamics 365 team, or even your entire business apps practice has experienced working together and you've got data from multiple teams on multiple projects, you might be able to establish some norms. Until then, here's what I recommend. If your project estimation scale uses a modified Fibonacci scale like 13, 20, 40, 60, and 100, or a powers of two scale, like 16 32, 64, and 128, group together, similar sized stories under each unit in the scale. For example, gather all your 13 point stories if you're using Fiche or all your 16 point stories if you're using powers of. I'm going to assume that you're using a modified Fibonacci scale like mine.

Ask the team how confident they are that they could develop everything in this feature sized story within one sprint if this was the only requirement the whole [00:18:00] team focused on. Again, you can play fist of five to help the team reach consensus. If they're confident that they could deliver it that size, move up to the next size in your scale. How confident are they? They could deliver a 20 point feature in one. If they're still confident, move up another size. How confident are they that they could deliver a 40 point feature in one sprint if they focused on nothing else? At some point, the team's confidence that they could deliver a large feature in one sprint will dry up. They hold up two

or three fingers in your fist of five game. Let's say that your team was four or five fingers confident of completing a 40 point feature in a sprint but not a 60 point feature. I'd use 40 points per sprint as our initial estimated velocity.

If the team is new and has little or new experience working together, you might wanna use a velocity range like 30 to 50 points, because 30 is halfway between 20 and 40 and 50 is halfway between 40 and 60. The velocity range reflects your team's experience working with these types of requirements with this customer or similar customers, and with each other.

An experienced team deploying an industry solution will often have a narrower velocity range than a less experienced team building a complicated novel customer application in a new domain. Next, use the velocity range 30 to 50 to help your team calculate how long it'll take to get all the features done in the product backlog.

In our example from the last lesson, the project had a backlog of 1052 points for releases one and two combined. Divide 1052 by 30 points per sprint. Then repeat the calculation this time with a velocity of 50. The result is that it'll take between 21 and 30 sprints to complete the project. That's 42 to 60 weeks, if your team is running [00:20:00] two week sprints.

Some agile practitioners think that what we're doing here is crazy. Attempting to estimate velocity before the team has ever worked together sounds nuts to them. Instead, they would rather use probabilistic forecasts that involve working together for a few sprints, gathering empirical data about the team's actual real world velocity building real features.

So would I. That would be much more accurate, but it's impossible for most Dynamics 365 and Power Platform teams, especially Microsoft partner teams, because we're pitching for new projects with customers we haven't worked with before. We can't just write a proposal that says, Hire us and we'll tell you how long the project is going to take and how much it's gonna cost after a couple of months of building up empirical data about our velocity that we can use to make a probabilistic forecast.

Well, you could take that approach, but you'd probably lose lots of opportunities to my team because we're able to estimate cost and duration using their techniques I show you in this course. . In the next lesson, I'll show you how I take the team's estimate of velocity and calculate how much the project is going to cost.

How much does it cost?

In the previous lesson, we learned how to estimate the velocity of our Scrum team building a complex enterprise business application. In that example, the team had estimated the total effort to build the application and deploy the first two major production releases at 1,052 story points. And their estimate of velocity range was between 30 and 50 story points per sprint. With that velocity, it'll take between 21 and 30 sprints to complete releases one and two.

All we need to estimate how much it'll cost is to estimate the cost of the team per sprint. Fortunately, the team member composition of scrum teams tends to be quite stable. We have a scrum master and some developers who arrive on the first day of sprint one and are there until the end of the project.[00:22:00]

There are, of course, some changes in team composition during long projects. We might increase the size of the team to bring in new skills, to balance the team's skills, or increase the team's capacity. But it's not like a traditional project team composed of analysts in the first phase, then the architects, then the developers, and then the testers. The project manager is usually the only consistent team member.

My recommendation is to ask your team of estimators, who estimated the velocity, to tell you how many team members they had in mind, and what skills that team would have to have, to deliver this project successfully. That's the scrum team you'll need to find if and when the project goes ahead so that you can use that to calculate the project's costs.

Here's how let's say the developers who estimated the team's velocity tell us that we'll need: a scrum master to coach the team; an analyst to assist the customer's product owner in refining the product backlog and ensuring there's a sufficient pipeline of user stories ready for development; two app makers to configure the Power Apps user interface and Power Automate flows; a .Net developer to develop Dataverse plugins and Azure components and to automate our pipelines and releases; a tester to create and execute test cases and build automated tests.

In this example, these are all close to full time roles. I call them intrinsic team members because they're all members of the scrum team in every sprint.

But you could also have extrinsic developers who you rely on occasionally or perhaps for a few sprints. These can include solution architects, user interface designers, or acceptance testing managers.

I don't include the product owner in my team because I'm expecting my customer to provide the product owner as well as subject matter experts, a change manager, a project manager, a system administrator, and any other roles that your customer is fulfilling that make up the whole project team.

Here's the next step after we've agreed the composition of our scrum team. [00:24:00] I take a simple spreadsheet and I list the team members in column A and their role in column B. In column C I add the daily rate for each of the developers we think might fulfill those roles.

In most Microsoft partner organizations project resourcing decisions are usually made much closer to the contracted project start date. But as my old manager used to say, " Never let availability get in the way of a good proposal."

In column D, I estimate the number of days per sprint that each team member will contribute towards this project. Some people only work part-time, others have responsibilities outside our scrum team. Everyone takes personal leave and public holidays, so even for someone working full-time in this team, I use an average contribution of nine working days over a two-week sprint. In column E, I calculate each team member's cost per sprint by multiplying their daily rate by the days per sprint.

In column G, I multiply the cost per sprint by the lower estimated number of sprints to calculate the project cost per team member. I repeat this calculation in column I using the higher estimated number of sprints. In the total row, I calculate the average daily rate, the average days per sprint, the estimated cost per sprint, the range of estimated total project costs: 1.21 to 1.72 million, in this example,

Now when our customer asks us, " How much is it going to cost?", we can reply, " We've estimated the effort in building what we think you need in release one and two, and the team it'll take to build it. We've estimated it'll take between 21 and 30 two-week sprints, and the average fees for our team will be 57,400 per sprint. The total cost will be between 1.21 and 1.72 million."

That's how I do it. Estimate the size and our velocity. Then derive the duration and the cost.

In the next lesson, we'll look at a [00:26:00] few different ways to help your stakeholders visualize your estimates. Then how to use estimates in your sales proposals.

Visualizing your estimates. by now. You should be able to use story point estimation to estimate how big your project is, then estimate your duration and running costs to derive how long it'll take and how much it'll cost. In this lesson, I'd like to share with you three ways of visualizing your estimates.

Visualizing your estimates can help you communicate estimates to your stakeholders to help them understand how factors like scope and team size impact the release dates and costs. The three visualization tools that I use are a scaled product backlog, a user story map, and a release burndown chart.

Here's an illustration of a typical product backlog at the start of a project. In this example, we've got nine feature sized stories. With size estimates ranging from 13 to 60 story points. The total size of the backlog is 266 story points. if the developers estimate their initial velocity to be 30 points per sprint, we can illustrate how long it'll take to complete nine sprints.

And if the burn rate of the scrum team is 60,000 per sprint, then nine sprints will cost 540,000. we could model a second scenario where the product owner is prepared to increase the size of the team to achieve the project faster. With a bigger team. The developer's estimate their velocity could be 50 points per sprint. Now they'll get the backlog done in six sprints with room to spare, but there's an additional cost that comes with having a bigger team.

The burn rate is gonna be 100,000 per sprint. Six sprints at 100,000 each will cost 600.

If you've ever heard of the Mythical Man Month by Frederick Brooks, you'll know that there's a limit to the size of a team and its effectiveness. You couldn't add 30 developers to the team and expect to achieve a velocity [00:28:00] of 300 points and finish the project in 8 days. But I find this kind of scenario modeling a useful exercise when we're discussing release dates, project costs, and team sizes.

That's our first way of visualizing our estimate. Just using the product backlog and adding some scales down the side of it.

Our next visualization is a user story map.

One of the issues that my product owners have had with the product backlog is that it's hard to know when a set of related features supporting a particular business process or stakeholder can be release.

User story maps were devised by Jeff Patton to help stakeholders visualize their product backlog in two dimensions, not just an ordered list.

We start with laying out the business process activities, the big steps taken to get something done. Under those, we have the smaller steps users take to achieve the activity called user tasks. The sequence of user tasks that follow the happy path of the business process are called the narrative flow.

Most business processes have alternate tasks that users can follow in certain conditions. We can arrange these under the user tasks in the narrative flow, in the order in which they're needed.

And although Patton doesn't like the word epics, that phrase is much more commonly used now than it used to be. Under the epics, we have the main features that our users need our application to provide them. Below those we have the additional features needed in the order in which they're needed. The further down the map, the lower the value of the feature

Now our developers can add their story point estimates to each of the features. We can sum the story point estimates at the epic and even at the stakeholder level. Then the product owner can slice the user story map into releases, which is a collection of features that will be developed and released together.

We can total up the story point estimates for all of the features in a release to estimate the size of that release. In this example, the team's estimated velocity is 50 points per sprint. The estimated burn rate for the team is 100,000 per sprint. [00:30:00] This means that the estimated cost per story point is 2000.

I love using physical user story map on the walls of conference rooms where the scrum team is working.

Alternatively, you can use user story mapping software. Spec flow for Azure DevOps is a popular one. My preferred user story mapping software is StoriesOnBoard, which can be used standalone or integrated with Azure DevOps or Jira.

The last style of visualization that I use with my stakeholders is the release burndown chart.

This visualization brings home the impact of scope on our timelines and costs, both at the start of the project and later if someone proposes adding some new features to our backlog. A release burndown chart is a chart displaying the work remaining on the Y axis. The estimated number of story points to turn the product backlog into increments of working business application software.

In this example, I've split the work remaining into three releases. Release one is 240 story points. Release two is 220 story points and release threeis 113 story points. Along the x axis is the duration measured in sprints. In an agile project each sprint has a predictable burn rate, so the X access also represents the cumulative costs.

Next, I use two estimated velocities to derive the landing zone for a particular release. In this example, if we have a team with a velocity of 30 points per sprint release, one will land in sprint eight. If the team's velocity is 40 points per sprint, it'll land at the end of sprint six.

Then I add landing zones for the other releases. You'll notice that even though release three is smaller than one and two, it's got a large landing zone because the story point estimates are cumulative, and we estimate very large backlogs less precisely than small ones.

Once the project gets going, it can be helpful for our stakeholders to see how the project is progressing using [00:32:00] updated release burndown charts.

This chart shows that release one was done in sprint seven. Release two will land sometime between sprint 12 and 14. Release three is now estimated to land sometime between sprint 15 and 16.

Backlog management tools, like Azure DevOps can generate release burndown charts for us, but I find that they need a couple of sprints worth of velocity data. So I create my estimated release burndown charts in Excel or PowerPoint before relying on Azure DevOps once the sprints are underway.

In this lesson, you've just learned three tools to help your stakeholders visualize your estimates: scaled product backlogs, user story maps, and release burndown charts.

In the next lesson, I'll show you how I use these visualizations to communicate with some of the most important stakeholders of all: prospective customers when you're creating sales proposals.

Estimates in sales proposals. In the previous lesson, I showed you the three visualizations I used to help my business applications stakeholders visualize the estimated size of the application's features and how long it'll take and how much it'll cost to build.

In this lesson. I thought it would be useful if I share with you my experience using these estimates and visualizations in proposals provided to prospective customers.

Most people taking this course work for a Microsoft partner, and you're probably familiar with estimating a project as part of your sales process. If you work for a Microsoft customer, then you might not be involved in creating sales proposals for your customers as such, but you might still be involved in developing business cases and pitching a project to get it approved. I hope what you learn in this lesson is still as useful.

In my experience of selling agile Microsoft business applications since 2008, there are broadly two types of sales opportunities.

The first is where you are engaged with a customer to do some discovery work.

The second [00:34:00] is where you're not able to do any discovery work at all, or not enough that you're able to create an ordered estimated backlog. You might find yourself in this situation if you're bidding on public sector opportunities for government departments.

Let's tackle the first type of opportunities first. This is when you've been able to work with your prospective customer and lead them through your discovery process. Your customer might have started with some sort of requirement specification, but you've been able to run workshops with stakeholders to convert that specification into an ordered estimated, product backlog.

There are lots of approaches for doing this. Your Microsoft partner organization might use Microsoft Catalyst or some other design thinking approaches that involve the users, uncover their pain points and potential delighters, and ensure that you can build an app that they'll love. During the discovery work, I like to co-create a user story map with my prospect's stakeholders. I'll then include the user story map and a release burndown chart in the sales proposal.

Sometimes the diagram is embedded into a document. Other times it's included as a slide in the presentation. Either format works well. I'll also include a description of my proposed team, our estimated velocity based on the skills and experience of this team. I recommend including photographs of the team members, and I encourage them to write a few words about their experience and how that experience will be useful on this project. In other words, make it personal, not a generic description or bio.

I also like to include an assumption about the team members I expect the customer to be able to make available to the project as well, especially the product owner. This way, there are no surprises later when we suggest that a senior stakeholder becomes a full-time member of our scrum team.

But, what if your opportunity is the second type of opportunity where you're not able to perform any discovery work? This is common when you're [00:36:00] responding to requests for proposals from government agencies. Public sector procurement rules often prohibit potential vendors from having any kind of engagement that could be seen to give them an unfair advantage.

Depending on the level of detail provided in the request for proposal, my team might have been able to reverse engineer a product backlog out of a requirement specification. Requirement specifications usually aren't force rank ordered. The closest you might get is a prioritized list of must, should, and nice to have requirements.

I usually group these into releases. In release one we'll deliver the high priority or must have requirements. Release two contains the medium priority or should haves. And release three contains the low priority or could have features.

If there's enough there to estimate the requirements using planning poker or affinity estimation, that's great. We add up the story point estimates of the high level features to arrive at the total estimate for the project. Otherwise, we'll have to use our experience and compare the size and complexity of this entire project with others that we've completed.

I compare projects based on the number of users, the Dynamics 365 or Power Platform apps that are being deployed, estimated complexity of the data migration and system integration work, and anything else we might be able to gather from the requirements. Experience working in the customer's industry, segment, and solving similar problems will of course help.

If you need to resort to estimating this size of an entire project, your story point estimation scale is likely to use numbers like 1000, 2000, 3000, 5000, 8000, and so on. At this resolution your estimates are wildly imprecise but, accurate enough to give your customer's stakeholders a rough order of magnitude estimate of duration and costs.[00:38:00]

An 8,000 point project with a scrum team delivering 40 story points per sprint will take 200 two-week sprints to complete the project. That's eight years and probably about 20 million dollars. You're gonna need another team.

Estimating fixed-scope, fixed-price, fixed date projects. In this lesson, we're going to address the situation of providing an estimate to a customer that asks for a fixed-scope, fixed-price, or a fixed date project. Or who asks for two of those things to be fixed. Or sometimes even all three, scope, price, and date to be fixed.

The good news is that your teams can provide estimates for fixed-price and or fixed date projects and successfully deliver those projects on budget and on time by adopting an agile approach.

My teams have done this on lots of projects and we love it. I'm sure your teams can also deliver fixed-price or fixed date agile projects, or both. Fixing the budget or having a fixed release date works because it keeps our product owner focused on the most valuable requirements and keeps our developers focused on delivering the simplest solutions to meet those requirements.

Strong product ownership with attention paid to the order of the items in the backlog is necessary for fixed-price, fixed date projects to be delivered successfully. If there are significant changes in direction in the scope, then you won't necessarily miss your budget or date targets, but you might deliver a Dynamics 365 or Power Platform application with a set of features that don't seem to work so well together.

If you are the scrum master for a Microsoft partner team, you'll need to bring your best coaching skills to your customer's product owner to raise her backlog management and stakeholder engagement skills to help the team stay on track and not get distracted from the highest value requirements.

It's important to recognize that when we offer fixed-price, fixed-date [00:40:00] projects, we're not fixing the scope.

We're saying to our customer, we estimate it'll take 10 sprints to deliver the features you've told us you want. Our cost will be fixed at 10 times our sprint burn rate and no more. We'll deliver a production ready application 10 sprints after we start and no later.

But we can't guarantee which features will be included in the application after those 10 sprints. Your product owner controls the scope by ordering the product backlog. It's up to your product owner to keep us focused on the highest value requirements so that we build the best possible application within the budget and timeline that we've indicated.

We've estimated which features we can deliver within those constraints, but that might change as we learn more about your requirements while we're building the features together.

The delivery fees can be fixed, the delivery date can be fixed. The scope could change.

What if a customer wants to fix the scope too? What if they ask you to deliver all the features they want for a fixed-price or by a fixed date? There are two ways I think you can fix the scope.

The first is to invest a lot of effort analyzing the requirements in advance. Instead of taking an agile approach of letting the requirements and the designs emerge while we build and review features, we're gonna have to spend months documenting all of the requirements up front. Then documenting our designs so that we have a contractual agreement about everything that we're building. If anything changes as we build and review the features during the project, we'll have to manage the changes through a change request process.

The result of nearly every change request is an expansion of the scope, an increase in the cost, and a delay in the release date. Even the process of raising, evaluating, and approving a change request requires effort and costs money.

Comprehensive analysis in advance, upfront detailed design, and change requests [00:42:00] are the opposite of an agile approach.

They are the tools we use in a traditional, sequential approach. A waterfall approach. A waterfall approach with a structured process works well for deploying simple applications such as an industry template, a personal productivity application, or anything involving prebuilt functionality and very little development.

But you're not here in this course, in the Customery Academy, where we build agile applications, if you're deploying simple apps with a waterfall approach.

I believe you'll be more successful in building complicated or complex, mission-critical, enterprise applications with an agile approach than you will with a waterfall approach. If you want to fix the scope of a project to build a complex, mission-critical, enterprise application, then good luck. But the odds are stacked against you.

The other way of fixing the scope is to constrain the development effort. For example, it can look like this. We will build your custom feature, which will be capped at four custom screens, up to four tables, 50 columns, one business process flow, up to three cloud flows, and one Power BI chart.

I sometimes see this in small projects, and I'm not convinced this approach works either. Those constraints mean nothing to most product owners who haven't worked with the Power Platform or Dynamics 365 before, and they can't possibly evaluate whether those constraints are reasonable or ridiculous.

Of the two options for fixing scope, analysis and advance or constraining effort, which one do I prefer when a prospective customer asks for a fixed-scope project?


My fixed-scope projects fail, and most project failures I've studied have involved an element of stakeholders with fixed-scope expectations.

After having done this for the past 20 years, it's my job, it's our [00:44:00] shared responsibility, to highlight the folly of trying to specify all the requirements in advance, and for those requirements to never change while we build the app. Fix the price, fix the date. You can't fix the scope. Run away if they try and force you to fix the scope.

You've been listening to the Estimating Business Apps podcast, episode four.

In episode five, we'll bring it home with answers to the 20 most frequently asked questions I get asked about estimating Power Platform and Dynamics 365 apps.

You'll also learn about a special offer to join my Estimating Business Apps video course, and all the value packed components that are waiting for you inside.

I hope you loved this episode and took something useful away that you can use in your next estimation workshop. This podcast has been made available free for everyone to use in hopes that some of you, enough of you, will support my efforts to create this kind of content by joining the Professional plan of my Estimating Business Apps course.

If that's something you're considering I'm humbled and honored.

Join me in the last episode to get your frequently asked questions answered, and find out about the special offer.

Until then, keep experimenting.