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

Join me to learn how to:

  • Slice user stories into an appropriate size for estimation.
  • Agree a standard story against the relative size of other stories can be estimated.
  • Use affinity estimation to quickly estimate a large set of stories
  • Use planning poker to estimate a small set of stories
  • Derive how long it will take to deliver the feature based on the story point size of the requirement

The Estimating Business Apps is a companion podcast to my Estimating Business Apps online video course. You can join the Estimating Business Apps course for free here: https://customery.com/estimating

The first three sections of the online video course are free. By joining the Professional Plan, your support helps me make my training available to as many business apps builders as possible.

Transcript

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

In this podcast, you'll learn how to quickly, accurately and confidently estimate your Power Platform and Dynamics 365 applications.

In this episode, you'll learn my method for estimating requirements for Power Platform and Dynamics 365.

This episode is the audio version of section three of my Estimating Business Apps online video course. Podcast episode three relates to course section three. If you've listened to the first two episodes. I'm sure you've got the hang of that by now.

Inside episode three, you'll learn how your team can slice user stories into an appropriate size for estimating. How you can set a standard user story against which the relative size all the other user stories can be compared.

And you'll learn two estimation techniques that my teams use - affinity estimation and planning poker - and which method is best depending upon your scenario.

Finally, you learn how to derive how long it'll take to satisfy a requirement based on its story point size.

I'm publishing all of the episodes of Estimating Business Apps together. The remaining two episodes in the series should be available wherever you downloaded this episode.

Estimating Business Apps by Neil Benson. narrated by Neil Benson. That's my voice. I, I'm reading it myself. Copyright 2024 Customery Pty Ltd.

Here's the third section, How to estimate requirements, from Estimating Business Apps.

Slicing stories. Hi, I'm Neil Benson from Customery. Welcome back to section three of Estimating Business Applications. Slicing stories into an appropriate size for estimating is the first step in estimating our requirements.

Requirements that are too small have far too much management [00:02:00] overhead relative to the value they bring. Changing a column name, adding a column to a view, changing the placement of a button. These are all too small because it'll take longer to capture the requirement, estimate it and prioritize it, than it will to develop it and deploy it into production. And the value from such small changes is negligible. If you've got any tiny requirements where there are clearly only a few minutes of work involved, I'd encourage you to combine them with other requirements until there is at least a couple of hours of work involved and justifiable value will be realized.

On the other hand, slicing stories usually refers to stories that are too big for our team to work on. We want to slice user stories up into stories that are small enough, that we can do lots of them in a sprint. Even when they are estimated appropriately big stories carry too much risk uncertainty and complexity for my liking.

My teams have had far more predictable delivery when we work with user stories that are small enough so that we get at least 10 stories done each sprint.

Here's how slicing works.

Let's take this example of requirement, "Enquiry management. To help students quickly receive correct answers to inquiries, as a student services officer, I can track cases from different sources through a consistent case management process through to resolution within one business day."

Our initial thought might be that it will take more than one sprint to satisfy this requirement. It's an epic user story, which we'll learn more about in section four. We need to split 'Enquiry management' up into smaller features, such as Case submission, Case routing, Case evaluation, Case resolution, Case escalation, and Case service levels.

We could even split up the Case submission feature into a smaller set of user stories: Online case submission, Phone case [00:04:00] submission, Kiosk case submission, Counter case submission and Chat bot case submission.

I find that the secret of splitting stories is this: each story must independently create some value for our stakeholders.

Being able to submit a case online and over the phone are both independently valuable. But if we split up the Case submission requirement into layers, such as create case form, validate case data, submit case data to Dataverse, and Create case security role, then there's no value unlocked until all of those stories are deployed together. Until all of those stories are done, a student services officer can't create a case.

Split into layers like that those stories are highly dependent, not independent. So split your stories up into small, but not too small, independently valuable stories.

Who should split stories? Our product owner always remains accountable for the product backlog and could split the stories herself. But in my Dynamics 365 and Power Platform teams, one of our developers usually has a background as a business analyst and is splitting and combining stories in the product backlog on the product owner's behalf. Setting a standard story. Our next step is for our team to agree a standard story. The standard story is the requirement against which we will compare all the other user stories.

To do this, I recommend finding a user story near the top of the backlog that is well understood by the team. This means that the developers and the product owner have discussed it and agreed the acceptance criteria, and we don't have any significant unknowns associated with it.

The standard story should be a Goldilocks size, not too small, not too big. Your teams should be comfortable completing about 10 stories this size every sprint. We call this our 3-point standard story. [00:06:00] Your team will then use this 3-point standard story when estimating the size of every other story in the backlog.

If the comparison story will require a lot less risk-adjusted effort than the standard story, then it's a 1-point story. A little less risk-adjusted effort, then the comparison story is a 2-point story. A little more effort then it's a 5-point story. And a lot more effort, then it's an 8-point story.

If the comparison story feels bigger than an eight point story, then it's a feature. You can learn more about estimating features in section four.

Here's an advanced practice that a couple of my teams have found useful. Instead of just having one 3-point standard user story, we agree a standard user story for each unit in our estimation scale so that everyone can refer back to what a 1, 2, 3, 5, and 8-point standard user story look like when we're estimating.

If you're co-located, print your standard user stories and stick them to the wall. If you're collaborating remotely then have a document or a Wiki page describing the standard user stories somewhere that team can easily refer to it before each estimation workshop. And then when a new developer joins the team, remember to include this guide and their onboarding training.

In the next two lessons, we're going to learn two techniques for estimating user stories as a team, afinity estimation and planning poker.

Affinity estimation. Affinity estimation is the first of two techniques I've used with my teams to estimate requirements quickly and accurately.

Here's how it works.

On a whiteboard or a wall, either a physical or virtual one, we arrange five columns to represent the five numbers in our user story point estimation scale 1, 2, 3, 5 and 8.

The standard user story is already on the board. I recommend a 3-point standard story. So it would be in the middle [00:08:00] column. We take a backlog of un-estimated user stories that we want to estimate. The first developer takes the first user story from the backlog and places it in the column she, or he, thinks represents the risk-adjusted size of this story compared to the standard.

Don't take too long and don't discuss it. Just place it on the board.

The next developer places the next story on the board in the column that they feel is appropriate. We keep going with each developer estimating one story in turn until all the stories have been estimated.

Then each developer, in turn, has an opportunity to question the estimate for one of the stories and make a case for changing the estimate. If a debate is necessary, time box it to 30 seconds, one minute tops. It can help with the product owner is available for a quick clarification, but the work to refine and discuss the stories should have already taken place before we started estimation.

The team keeps going until all the cards have been estimated and all the developers are satisfied with the estimates of all the cards, or at least can live with the estimates, some compromise will always be necessary.

Affinity estimation works best when there are lots of stories to estimate, usually 30 or more, and where there are eight or fewer developers estimating the stories. It's a great technique to use at the start of a project or a major release when you need to quickly estimate a lot of requirements.

Afinity estimation doesn't require any special tools or apps and works just as well in person with index cards or sticky notes as it does remotely using a tool like Miro, Mural or Microsoft Whiteboard.

In the next lesson, you'll learn about another estimation technique planning poker.

Planning poker. Planning poker is the second of two estimation techniques that my [00:10:00] teams use, and it's the one that we use most often.

Planning poker is a variation on the wideband delphi estimation method, which dates back to the 1960s.

Here's how it works.

One of the team, usually the scrum master or product owner or a business analyst if one of the developers has been acting in that capacity, chooses a user story from the backlog of un-estimated stories and spends a moment describing it. The developers can spend a moment asking any clarifying questions.

All the developers estimate the user story silently and simultaneously. All the estimates are revealed together. This prevents anchoring, which is when the first person's estimate creates a bias that affects everyone else's estimates.

Developers with the highest and lowest estimates can take a moment to justify their estimates before the team plays again until consensus is reached.

Planning poker gives the team an opportunity to discuss the stories and eventually reach consensus on the estimated effort. You can use time boxes to constrain the discussion if needed, but there's no doubt that planning poker games can sometimes drag on unless tightly facilitated.

Planning poker works best when there is a small number of user stories to estimate, Usually usually 20 or fewer, and where there are eight or fewer developers.

It's a great technique to use towards the end of each backlog refinement workshop, when the refined stories are fresh in everyone's minds.

You can play planning poker with physical decks of cards. You could use the ace 2, 3, 5, and 8 cards from a deck of traditional playing cards. And there are even custom planning poker decks available to buy.

There are lots of different apps available on the Apple App Store or Google Play Store. You could probably build one in Power Apps. If you're so inclined. I've even used the Calculator app on my phone, [00:12:00] when I'm stuck in a pinch.

There are also planning poker apps and plugins available that integrate with Azure DevOps or JIRA, if your team finds those useful.

You've now got two estimation methods, affinity estimation and planning poker, that you can use for estimating user stories. In the next lesson, you'll learn how to estimate how long it'll take based on knowing the size of your requirements.

How long will it take? In this lesson, we're going to take the estimated backlog of user stories and use that to estimate how long it'll take to get all of the stories done.

This method works well for estimating small product backlogs. For example, it works if you've got 100 or fewer user stories in the 1- to 8-story-point range. That's usually about two to three months worth of work for a typical business apps team.

If you need to estimate how long it'll take and how much it'll cost for a large, complex project or application check on section 4.

Here's how it works.

If you split your user stories so that they are small enough to implement about 10 of them within one sprint, then take those top 10 user stories from your product backlog and start with those.

It works best if most of the user stories are part of the same feature, rather than 10 unrelated stories from 10 different features.

Does your team feel like they could get all 10 stories done within one sprint?

To check that confidence play fist of five. Each developer holds up their hand with a number of fingers showing corresponding to their confidence. Five fingers for completely confident down to zero fingers for zero confidence.

If any of the developers show three fingers, ask what it would take to improve their confidence. Usually it means that dropping one of the small stories, then play fist of five again, until everyone is showing four or five fingers.

On the other hand, get it, [00:14:00] if you play fist of five and everyone shows four or five fingers on the first game, then add another small user story and play again. After two or three rounds, you'll reach a consensus on the number of story points and the stories that your team feels it can confidently deliver within one sprint.

This is their predicted velocity.

Here's an example, your team has estimated a product backlog with 45 user stories varying from one story point to eight story points in size. The total estimated size of the backlog is 125 points. After playing fist of five, the team has reached consensus that they can get the first nine stories done in the first sprint. The total size of these stories is 25 points. Their predicted velocity is 25 points.

125 points in the backlog divided by 25 points per sprint is five sprints. Each sprint is two weeks, in our example, which means it'll take 10 weeks to complete this backlog. Now we can tell our product owner, "Based on the estimated risk-adjusted size of the requirements and the predicted amount of work we can complete within an average two-week sprint, we estimate it'll take five two-week sprints to complete all the work."

There you have it. That's how I estimate Dynamics 365 and Power Platform applications, using the story point estimation. We write our requirements as bite-sized user stories, establish a standard 3-point user story, use affinity estimation or planning poker to estimate the product backlog in risk-adjusted story points by comparing every story to the standard, and then we estimate our predicted velocity and apply that to the backlog to estimate how long it'll take.

In section four, you'll learn advanced techniques for estimating features and epics [00:16:00] all the way up to complex projects, and lots of more advanced methods besides. I look forward to seeing you in there.

You've been listening to episode three of the Estimating Business Apps podcast.

In episode four, you'll learn how to level up your estimating game to estimating entire business applications. The next episode corresponds with section four of my video course, which is only available in the paid Professional Plan, but you can get access to the audio version. And the next episode of this podcast.

Then in episode five, we'll conclude the Estimating Business Apps podcast with answers to the 20 most frequently asked questions I hear when it comes to estimating Power Platform and Dynamics 365 apps. We cover everything from when should we estimate requirements, to how should we report velocity to our stakeholders? And, should we estimate non-functional requirements?

I hope you've learned something from, and enjoyed, this Estimating Business Apps podcast episode. I want to make this content absolutely free to everyone regardless of whether or not your organization decides to invest in my Estimating Business Apps video course for you and your team. I hope it does. After all, learning how to build amazing business apps isn't just a matter of some Microsoft technical certifications.

Join me in the remaining episodes of Estimating Business Apps and find out how you can get an exclusive discount to the online video course.

I'll see you in episode four, How to estimate entire applications.

Keep experimenting.