Welcome to Estimating Business Apps episode 5. This is the final episode in the Estimating Business Apps podcast mini-series.

In this episode, I introduce the final section of the Estimating Business Apps course.

Join me as I answer 20 frequently asked questions about how my teams estimate Power Platform and Dynamics 365 applications:

1. How can we explain story points to stakeholders?
2. What are the advantages of story points?
3. Aren't story points equivalent to time?
4. When should we estimate backlog items?
5. How often should we update our estimated velocity?  
6.  How should we report our velocity to our stakeholders?
7. Should we fill up our sprint backlog up to our estimated velocity?
8. When should we split epics or features into stories?
9. Should we estimate bugs?
10. Should we estimate non-functional requirements?
11.  Should we estimate sub tasks?
12.  How do we get quicker at estimating?
13. When should we re-estimate stories?
14. Why does the whole team need to be involved in estimating?
15. How does estimating work with multiple teams?
16. How do we prevent estimate inflation?
17. Can we compare teams' velocities?
18. Can we track the velocity of individual developers?
19. How do we reach consensus when our estimates are different?
20. How do we create perfect estimates?

The Estimating Business Apps is a companion podcast to my Estimating Business Apps online video course.

Using the discount code in this episode, you can register for the Estimating Business Apps course here:

https://events.humanitix.com/estimating-usd

And my Successful Scrum for Microsoft Business Apps course here:

https://events.humanitix.com/scrum-usd

Thanks for your support. Your support for my paid courses helps me keep creating free content.

In this podcast you've learned how to estimate Power Platform and Dynamics 365 applications, so that you can answer your stakeholders two favorite questions, "How long is it going to take?" and "How much is it going to cost?"

In this episode, I share answers to the top 20 questions I get asked by Power Platform and Dynamics 365 professionals like you, about how my teams estimate complex business applications. Hopefully, any of if your remaining questions are addressed here today too. If there's anything else you'd like to know, by all means shoot me a message on LinkedIn, or email to neil@customery.com.

And stick around to the end of this episode for a special offer to come and join my Estimating Business Apps video course. If you've enjoyed the podcast, I think you'll love the video course. I hope you love it. Your support for the online course is what makes the podcast possible.

Welcome to section five where we're gonna cover frequently asked questions about estimating business apps. Let's start with,

How can we explain story points to stakeholders?

I hope you liked the analogy of estimating trails to estimating requirements. That's why I included it in my course. You're welcome, of course, to use that analogy with your stakeholders too.

You could estimate the length of the trail compared to other trails and then adjust the distance based on the difficulty such as steep climbs, the condition of the trail or even the weather. Then any trail runner can estimate how long it'll take them based on their speed. In the same way, we don't know how fast the developers who work on your requirements can go, but we can estimate the size of the requirement compared to other requirements and then adjust them for risks, uncertainty, and complexity . Then the team can estimate how long it'll take them based on their average velocity. The team uses its recent average velocity to plan how much work it can get done in each upcoming sprint. We use this story points scale 1, 2, 3, and 5 for estimating smaller requirements, and we use 13, 20, 40, 60, and 100 for estimating large requirements reflecting the natural ambiguity of estimating big, complex pieces of work. We can't say for certain how long it'll take the team to deliver an eight story point item because the team's velocity changes over time. But we can say that eight point items take on average four times as much effort as two point items.

What are the advantages of story points?

Estimating in story points has some clear advantages compared to estimating in time, which is how most teams estimate and how most teams create bad estimates.

Firstly, time-based estimates are nearly always rooted in the developer's own experience of how fast they could get a piece of work done.

If they are a developer and familiar with the development work required, their estimate will be lower than the same requirement estimated by a tester who understands all the complexity of the different test scenarios. Same piece of work, but two divergent estimates because each developer is estimating effort in units of time.

Story point estimates are team based and relative. The team reaches consensus on the risk adjusted effort involved to get all the work done, including development, testing and everything else. And we compare that to all the other pieces of work. This has proved much more accurate than individual estimates rooted in units of time.

The second reason I find that story point estimates are better than time based estimates: they promote consensus from a cross-functional team that's got all the skills needed to get the work done. Too often, time based estimates are left to a single pre-sales consultant, an architect, or a senior developer.

What does change is our velocity. Taking velocity changes into account when deriving our timelines and costs is easy. We don't need to waste hours or days re-estimating all of our requirements. Those are my three favorite advantages of story point estimation. They are relative not absolute, they're created by teams not individuals, and we don't waste time re-estimating story points when there's a change in our team.

Aren't story points equivalent to time?

When your team has been using story point estimation for a long while, you'll have gathered enough empirical data that you could look back and plot a chart of estimated story point sizes, and actual time spent on each item. Agile proponents who favor probabilistic forecasting

use scatter plots to visualize cycle times. Another type of chart we could create is a distribution chart, and with enough data, we'd expect a bell-curve shape illustrating normal distribution. We would use the data to plot the mean. And if we did this for one point stories and discovered that their mean elapsed time was 6.83 hours. But there are often big variances.

Some one point stories are done in an hour. And a few outliers took several days.

When should we estimate backlog items?

There are two occasions my teams estimate backlog items. The first is before the start or right at the start of a project . At this stage, we're trying to estimate the effort of building the whole application. The backlog is split into releases and each release is full of epic or feature sized user stories.

We'll recalculate the duration and the costs after a few sprints when we have some actual velocity data.

The other time we estimate is at the end of our backlog refinement workshops . We hold these twice a sprint until we've got a buffer of stories ready for development, and then we slow down the pace and hold backlog refinement workshops about once a sprint.

The workshop usually lasts an hour or an hour and a half, and it's a chance for the product owner and our business analyst to familiarize the rest of the team with the underestimated items at the top of the backlog, and for the team to ask clarifying questions and usually agree a candidate design idea for how they might achieve the requirement.

They'll spend the last third of the workshop estimating those items using planning poker.

You can estimate requirements anytime you like, but there's one time I would advise you to avoid it, and it's during sprint planning. By the time you get to sprint planning, your team should already be familiar with the items near the top of the backlog. This is the time for the developers to agree on which of those items they're gonna move into their sprint backlog.

How often should we update our estimated velocity?

My teams will update their estimated velocity every sprint, based on the average from the last three sprints . They'll use this updated estimated velocity in sprint planning to plan how much work to bring into their sprint backlog.

And we try and avoid doing that by updating the release plan just every three or four sprints or so.

How should we report our velocity to our stakeholders?

If you've told your stakeholders your estimated velocity and showed them how you used it to derive how long it'll take and how much it'll cost, it's only natural that they'll be interested in your actual velocity every sprint. I've had stakeholders ask about our velocity and sometimes it can be used as a healthy conversation.

For example, if they ask, is there anything we can do to help the team remove any impediments to their velocity? Or, is the team getting everything it needs from us to get all its planned work done? Those are productive conversations to have with your stakeholders. But, some stakeholders can try and weaponize velocity and use it to punish your team.

Why the heck didn't you achieve your velocity commitment last sprint? Or, is the team planning to work overtime this weekend to hit the velocity target? Those are unhealthy, counterproductive conversations to have with stakeholders. Depending upon the environment you're working in, I would tell our stakeholder, our team's velocity, if they asked.

If we have healthy conversations about it, then I'd mention it as part of our sprint review, without leading with that conversation. If we have. Unhealthy conversations about velocity, then I'd had a private conversation with whoever is asking about velocity, but I wouldn't include it in the sprint review or any kind of progress reports.

Should we fill up our sprint backlog up to our estimated velocity?

We don't estimate the effort spent on spikes or chores, although some teams do. We just reduce our committed capacity instead. Best case scenario is that we'll get all of our items done ahead of schedule and have time to finish a couple of small bonus stories or get started on some bigger ones from the product backlog.

Sometimes, we'll over commit. If our estimated velocity is 50 points in the next sprint, We'll commit to getting 60 done. For example, we do this when we don't have any spikes or chores to work on. When the distribution of stories among the team is favorable and everyone's going to get to play to their strengths.

And nearly all of the stories align to the sprint goal, so there's going to be lots of economies of skill and scale when we're all working towards the same outcome. Most of the time, though, we just fill our sprint backlog up to the number of story points just under our estimated velocity, and that works well for us.

When should we split epics or features into stories?

My teams write epic and feature sized user stories and estimate them at the start of a project. We try not to split those big items up into smaller items until we're about to start work on them, usually a sprint or two in advance. So if we're in sprint 12 and we think we might start work on the certificate generation feature in sprint 14, Then we'll split up that feature item now into smaller items and begin refining and estimating them during sprint backlog refinement activity in sprints 12 and 13, so that we're ready to start development in sprint 14.

25% of the time, the total will be less, 25% of the time, it'll be about the same, and half the time, it'll be more. This is perfectly natural. New requirements are bound to emerge now that you're about to start development. That's okay. Don't panic. What you'll usually find is that lots of the small stories that can support our certificate generation feature are not necessary right now.

They're not valuable enough to prioritize in this release, and they can be tucked into the bottom of the backlog. Maybe we'll do them later if we have capacity, but they're not essential to shipping the certificate generation feature that's needed now. In effect, our product owner uses that original 40 point estimate as a constraint.

So that our release doesn't go over budget.

Should we estimate bugs?

I don't recommend estimating bugs, but some teams do it anyway. My teams assign story point estimates to work that our stakeholders find valuable. That means we really only estimate epics, features, and stories. And we only track story points for those item types in our velocity calculation.

Our backlog also has chores and spikes and very rarely a bug or two, but we don't estimate these types of items. The reason why is that we define velocity as the speed with which we're moving towards the product goal. If we spent an entire sprint squashing bugs, then we wouldn't have moved the application any closer to the product goal.

If our sprint backlog includes a lot of bugs, spikes, and chores that simply need to get done, then we simply reduce the number of estimated user stories we commit to getting done that sprint. If our estimated velocity for the next sprint is 50 points, We might commit to 25 or 30 points of user stories, knowing that the remaining capacity is going to be spent working on work that isn't directly valuable to our stakeholders, but needs to get done by the team.

Should we estimate non functional requirements?

In all our Dynamics 365 and Power Platform teams, there will be work that the developers have identified needs to get done that hasn't been directly requested by a stakeholder and isn't directly valuable to them. Sometimes it's work to pay down technical debt and the developers need to persuade the product owner it's worth doing.

I describe these types of product backlog items as chores. Chores are the work that the developers need to get done but are not directly valuable to our stakeholders. Updating your suite of automated performance tests will help the team build a better application, but it probably isn't something that a user has requested, and it's unlikely your stakeholders would find it directly valuable.

That's an example of a chore. Sometimes it's a bit of a borderline decision whether an item is a chore or a story. If your information security team requests completion of a pre release security assessment of your application, then there's an argument to be made that this is a stakeholder request. With direct value, at least to the InfoSec team.

If you decide to call them user stories and estimate them, then this work will be included in your velocity. If your stakeholders are putting you under pressure to increase your velocity, then there's a risk of story point inflation and putting points on everything. I've had teams ask whether they should have estimated stories for time spent in scrum events.

Should we estimate sub tasks?

Some teams use sub tasks as a child item type of a user story. A few teams even go a step further and estimate those sub tasks. And scrum trainer Mike Cohn used to recommend estimating sub tasks in hours, but estimating stories in story points, which I never really understood.

But we don't break it down into subtasks. The extra work of creating, capturing, and tracking sub tasks isn't worth it for us. Estimating sub tasks in hours definitely isn't worth it. Even if your team finds sub task tracking to be valuable, I'd avoid estimating sub tasks or tracking time at this level.

Experiment using sub tasks if you think they might solve an issue that your team faces. But often, they're simply a carryover from a pre Agile methodology, and you can leave subtasks behind as your team adopts an Agile approach.

I've been there. I've sat in three hour planning poker estimation workshops where some stories take 30 minutes of vigorous debate and three or four rounds of planning poker to reach consensus. Those workshops are painful. Estimation should be quick. The goal of estimation is to help us plan our capacity each sprint and help our stakeholders, particularly our product owner, to order the product backlog and plan releases.

Estimates should be quick. Reasonably accurate and confident, but time spent bogged down in estimation workshops is valuable time misspent. Often the reason why estimation takes so long is that the team feels pressure to produce unreasonably precise or accurate estimates. This can happen when stakeholders track velocity, punish the team for work that they felt took longer than estimated.

If there are stakeholders who get upset or angry about variances between estimated and actual, that's unhealthy. And your scrum master will need to coach that person, perhaps even coach them somewhere far away from your product team. We're aiming for estimates that are right. On average, this means that our estimates will be too low.

As often and by as much as they are too high. Some developers are tempted to underestimate the work. Often they focus only on the part of the work that they're good at and can't see the other work that needs to get done. Or they can't imagine the risks and complexity involved with getting the work done.

And it won't. It'll probably spill over. Instead, you'll need to use an 8 point container, even if your user story doesn't fill the 8 point container all the way up to the top. Agree what consensus looks like. It doesn't have to mean that every single developer must estimate the same number.

Perhaps your team would be satisfied if the highest and lowest estimates were discarded and the remaining estimates were the same number. Don't try and design the solution. It's great if the developers have an agreed design in mind when they estimate the story, but it's not strictly necessary. The design can emerge when the development starts once the story is included in a sprint.

I hope those four practical tips and creating a safe estimation environment in which estimates are accurate on average helps your team confidently produce estimates quickly.

When should we re- estimate stories?

I think it's okay for teams to re estimate stories occasionally, but I try not to make a habit of it. Here's an example where my team re estimated stories recently. In June, we had helped a prospective customer create a user story map to visualize their features and define the scope of their project.

After just a few hours working with them, we estimated all the feature sized stories on the user story map to help them derive the budget necessary for the first two releases. It was four months before the budget was in place and a procurement exercise awarded the project to our team. And then we could mobilize our developers and dive deeper into the backlog.

After a couple of weeks, we were asked if our estimates had changed. And so we quickly re estimated all the items based on what we now knew about the requirements. Some requirements had become more complex. A one way integration had evolved into a need for a bi directional near real time integration.

Like I said, we will sometimes re estimate items if there is a compelling reason to spend our time on it, but we'd rather spend our time building features. One thing I don't think I've ever done, and I'd encourage you to avoid, is to change the estimate after the work is done. If you estimated it as a 5 point user story, but you actually spent as much effort on it as you do an average 8 point user story, learn from that and move on.

Don't change the estimate retrospectively. If you start doing that, you'll find yourself increasing the estimate for stories that took longer than expected, but I bet you, you'll never decrease the estimate retrospectively for stories that took less effort than expected. So you're cheating yourself if you start this retrospectively changing estimates game.

The one other time my teams are tempted to re estimate work is when they start a user story in this sprint, but they don't get it all done. Should they re estimate the work remaining and split the story points between the two sprints? No, don't do that. The user story isn't done. It can't be released.

There might be a reason why the product owner decides not to carry that story over into the next sprint and it might never get done. No partial credit. Don't re estimate half done stories.

Why does the whole team need to be involved in estimating?

Or size of project, a particular range of technologies, or customer industries, and approaches. For the same reasons that we value diversity in our teams. We value diversity in our estimates, diversity of expertise, diversity of skills, diversity of experience, diversity of industry, and diversity of viewpoints and cultural backgrounds too.

Having several developers take part in estimation makes for more robust estimates. I could share hundreds of anecdotes of situations where I've estimated low, and I've been advised about the complexity of the test scenarios. Or I've estimated high and I've subsequently learned about a new feature or an enhancement that simplifies the work.

How does estimating work with multiple teams?

I've worked on several enterprise projects where there are several teams organized into different work streams. For example, at the University of New South Wales, we had a team building an app for the Future Students Division and another team building an app for the Student Services Division.

At the Royal Automobile Club of Queensland, RACQ, we had work streams for Power Platform app development, actually three teams. CPQ app development, which is configure price quote, uh, we have another work stream for systems integration, data migration and analytics, and business and change. I picked these two examples because they illustrate that multi team estimation can be easy.

Each team used the same estimation method. We shared the same definition of done, we used the same estimation scale, we calibrated our three point standard stories, we didn't estimate bugs or non functional work, or claim points for half done stories. At RACQ, it was altogether more complicated. Our Power Platform teams used the same estimation method.

But the CPQ vendor estimated in ideal hours, and the systems integration team didn't estimate anything at all. And it was a mess. When the product owner would ask how big a new feature was, she'd receive our estimate in story points, the CPQ estimate in hundreds of hours, and a vague yes from the integration team.

My hard won advice is to ensure that all the teams building apps within your organization Use the same estimation method. Uh, admittedly, that's tricky if those teams are a bunch of different Microsoft partners that each have their own internal estimation method and won't budge. That's why I'm hoping that Microsoft customers and partners everywhere adopt StoryPoint estimation.

So thanks for being part of my mission.

How do we prevent estimate inflation?

Over time, you might find that you begin to inflate the estimates assigned to user stories. The size of story that you used to regard as a one point story gradually slips into the two point bucket, two point stories drift towards a three, and so on. This happens because we tend to remember the underestimated stories that were delivered later than expected much more vividly than the overestimated stories that were finished earlier.

That's not really a sign that you're running faster. To keep your team's estimates grounded, I recommend comparing some recent stories back to that standard story you used at the start of the project during your next retrospective. If you notice story point estimation, brainstorm why this might be happening.

Sometimes it's because the team repeatedly hits unexpected delays, especially waiting for dependent teams to complete a task. These delays have a far bigger impact than you anticipated in your standard story. Adding an additional couple of points to your estimates might seem like a natural way of dealing with these delays, especially if it keeps your team's velocity looking good.

But your real velocity isn't good. It's worse than it could be because you're trying to inflate your way out of the problem. A better way to deal with this situation is to confront the people whose work you are dependent upon. Identify and blast the blockers. Perhaps your requests are going to the wrong person, or they're incomplete when they're submitted.

These kinds of issues can quickly be resolved. Help other teams to help you, and keep your real velocity.

Can we compare teams velocities?

It can be tempting to compare the velocities of different teams, especially if you're a program manager for a Microsoft customer and you've got several different delivery teams, or you're a practice manager for a Microsoft partner. Although I recommend that teams working within the same organization have shared definitions of ready, estimation scales, standard stories, and approaches to estimating non functional work, there's still going to be so much variation in how teams track their velocity that it's foolish to try and compare them.

Can we track the velocity of individual developers?

In a word, no, don't use velocity to track productivity, effectiveness, or performance of individual developers or, or the team. Velocity is a useful tool for the team to plan its capacity in each sprint. It's also useful for product owners, ordering the product backlog and planning a release.

Velocity is not a key performance indicator that you can use to measure the performance of the team or an individual. Besides. Developing business apps is a team sport. Microsoft might even call it a fusion team sport. User stories aren't done by one developer. In my teams, we have three or four people involved in each user story.

And the last person to own it is either another developer, peer reviewing it, a tester validating it, or a user verifying it. There's no one single person to credit with getting the card done. Managers. You'll have to find a better way of assessing individual performance and growth of the members in your team.

Velocity is not the metric you're looking for.

How do we reach consensus when our estimates are different?

With all the best intentions, my developers who've been working together as a scrum team for four years still don't always agree first time on their estimates for every user story. Yeah, tragedy if they did, because it's in the discussions about the divergent estimates where we learn so much about the story and about each other's assumptions and ideas about the story.

I use indefinite phrases like sometimes, perhaps, possible, or maybe. I avoid definite phrases like always, never, or none, or every. Definite phrases sound argumentative and lead to arguments. Indefinite phrases open us up and are stubborn developer to compromise. Early in your project, your team should also agree how it will quickly reach consensus when we have divergent estimates after a couple of rounds of planning poker.

For example, you could go with the majority, whichever estimate has the most support wins. Go with the highest, the most conservative estimate wins. Go with the average. I don't like using the mean of all the developer's estimates because the most pessimistic and optimistic estimates can really skew the mean.

Instead, either use the median, which is easiest if you have an odd number of developers, or eliminate the highest and lowest, and then use the mean rounded to the nearest, usually rounded up, depending upon how conservative your developers are.

How do we create perfect estimates?

This is the last video lesson in the Estimating Business Apps course. I hope you've realized by now there's no such thing as the perfect estimate. The only way to know exactly how long it's going to take and precisely how much it's going to cost is to build it first.

Estimating should be quick, accurate, and confident, but don't strive for pinpoint precision to the nearest hour or dollar. Perfect estimates are the enemy of good estimates. Get out there and get it done and keep sprinting.

You've been listening to episode five, the last episode of the Estimating Business Apps podcast, which covered section one of my online video course with the same name.

I hope you've enjoyed and learned something from this podcast mini series. My goal is to make this content free for everyone, regardless if you decide to invest in the Estimating Business Apps video course.

The Estimating Business Apps Beginner plan is free. But it only includes the first three sections. The Professional plan unlocks sections four and five, and that certificate of achievement that everybody's after. It costs $199. But if you use discount code, AMAZINGAPPS, that's all one word, you'll get a $50 discount on the Estimating Business Apps Professional plan. And. You can also use the same discount code to get $50 off my Successful Scrum from Microsoft Business Apps course too. Links to the registration page are included in the episode description.

And if want your whole team to join, there's a 20% discount when you register five or more people, basically you get five registrations for the price of four. Or if you want to go mega and enroll your entire business applications practice, and have 10 or more consultants, shoot me an email and I'll set you up in my new corporate learning management system. So your practice leader can manage consultant registration, and review consultants progress through my courses.

I really hope you can join me on support this podcast. Just before you go. We've got a few minutes for some trivia about the making of the Estimating Business Apps course and podcast.

The original content of the Estimating Business Apps course was a module in my Winning Agile Projects masterclass, but there was enough demand for this one module that I launched it as a short course. It was originally announced in late 2021 and I thought it would take about three months to complete. But our house flooded in February 2022, and I had to shoot the remainder of the course in an echo-y one person rented office. It took six months more than originally estimated to release the course. How ironic is that for course about estimation? Uh, talk about risk management.

I hope to launch other modules from Winning Agile Projects masterclass as standalone short courses, but given how busy I am with Superware these days, I can't make any promises, or commitments, or forecasts about release dates.

Qualifying agile opportunities. Pitching an agile approach. Creating compelling agile proposals. And closing agile contracts.

Let me know which of those topics, you'd like me to make a short course about next.

And if you're still on the fence about joining the online course, let me leave you with a couple of testimonials from students who have completed the professional plan.

Christian Gosselin, principal consultant with powerple consulting in Canada said, "I feel more confident and prepared to estimate agile projects. I highly recommend this course to anyone who wants to improve their estimating skills and deliver better outcomes for their customers."

Rita Patly, a senior consultant with Incremental Group in the UK, said, "Best way to learn project estimation. Valuable and to the point explanation. I enjoyed the course."

And John Burston, a Power Platform specialist at Rialto IT Services in the UK, said, " Both thought provoking and credible, neil provides real-world examples of how his team estimated the most valued work required to deliver client projects."

Thanks to all those Customery Academy students for their kind words, and to all the others who have left testimonials and reviews. I really appreciate your feedback.

Remember, you'll find the registration link in the show notes. The discount code that you need to type in is AMAZINGAPPS, all one word. The professional plan is $199 before the $50 discount. Keep experimenting.

Take it away, Tom.