Estimating Requirements for Your Microsoft Business App

Neil Benson: [00:00:00] Welcome to Amazing Applications episode 129. G'day, I'm Neil Benson from Customery. My mission on this podcast is to help you apply an agile approach and build amazing Power Platform and Dynamics 365 apps that your users will love. 

You'll find show notes with links and a transcript from this episode at https://AmazingApps.Show/129. This is the third and final episode giving you a sneak peek into my new online course. It's called Estimating Business Applications. Check out episodes 127 and 128 to listen to sections one and two of the course.

Estimating Business Applications is a free online course for everyone involved in estimating business applications. Whether you're in sales or business development, through to presales and delivery. It's gonna give you a structured, proven set of tools to quickly, accurately and confidently estimate how long it'll take and how much it'll cost to build a business app your stakeholders are asking for. 

Estimating applies just as much to Microsoft customers as it does to Microsoft partners. So if you work for a Microsoft customer, I think you'll find the course useful too. 

This episode is a sneak peak of section three, Estimating Requirements. There are five video lessons in this section of the course, and I've rolled them all into one podcast episode for you. I'm gonna share with you how to slice user stories into the right size for estimation, how to agree on a standard story, how to use affinity estimation or planning poker in your estimation workshops, and how to derive the duration after you've estimated the size so that you can answer the question: how long will it take? 

If you wanna take the online course with [00:02:00] the videos and quizzes, you can join for free by following the link in the show notes at https://AmazingApps.Show/129. I look forward to welcoming you into the course until then here's section three, Estimating Requirements.

 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 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 [00:04:00] 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 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 [00:06:00] 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. 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 [00:08:00] 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 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 [00:10:00] 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 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.

[00:12:00] 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, 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 [00:14:00] 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, 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 [00:16:00] 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 all the way up to complex projects, and lots of more advanced methods besides. I look forward to seeing you in there.

 That was an audio sample of the lessons in section three of my Estimating Business Applications online course. You can join the course and get the video lessons and quizzes for free at https://AmazingApps.Show/129. 

Until then, well, I think you know what to do. Keep sprinting.