Advanced Estimating Q&A

Neil Benson: [00:00:00] Remember, tracking velocity is for the scrum team's benefit. If your annual performance bonus is tied to your velocity, stop what you're doing. Thanks for playing. Try harder at Scrum next time. 

Welcome to Amazing Applications episode 126. I'm your host Neil Benson. 

Welcome back to another episode of Amazing Applications. In this episode, I'm gonna be answering some questions about estimating your business applications. You'll find show notes for this episode at https://amazingapps.show/126.

I've released a new course called "Estimating Business Applications", where you can learn how to quickly, accurately and confidently estimate your Dynamics 365 and Power Platform apps so that you can answer those two questions your stakeholders keep asking, "How long is it going to take and how much is it going to cost?"

The first three sections of the course are now available for free. You can join at https://customery.academy/courses/estimating. There's a link in the show notes for this episode, if you can't remember that long URL. 

Thanks to everyone who has joined so far, given me your feedback, and sent me your questions. Let's answer a few of them. 

First up, Tanika wants to know, 

Tanika: "Should we re-estimate items in our backlog after we're done, because they were easier or harder than originally expected?" 

Neil Benson: Thanks for your question, Tanika. Whether or not your team finds it valuable re-estimating items depends on, I guess, why you're estimating in the first place.

My teams estimate the size of product backlog items so that we can derive how long they'll take given the size and speed of our team, and therefore how much they'll cost. 

Our stakeholders. Use this information to agree, budgets and prioritize their requirements. Re-estimating items after they're done, wouldn't help. By then the budgets are old news and the remaining requirements have already been [00:02:00] prioritized. 

If your team re-estimate items after they're done, it'll also result in two different types of estimates in your backlog. One type is the estimated effort that was assessed before development had started. And another is the actual effort assessed after the development was complete.

These are completely different metrics, which makes it very difficult to track work completed and work remaining since one is actual and the other is an estimate. I can imagine this will only make your life and your stakeholder's perceptions of your estimates even more confusing. 

Look, I can understand the temptation to re-estimate items, especially if your team is tracking its velocity and takes pride in the accuracy and quantum of that velocity. You'll probably also find that developers are very keen to re-estimate items up, make them bigger when they were more difficult than originally estimated, but maybe not so eager to re-estimate items down and make them smaller when they were easier than originally estimated.

Really velocity should only be used to help developers plan how much work to take on during sprint planning, and to help the product owner estimate roughly, roughly when product items might get done. If stakeholders are using velocity to measure their team as some sort of KPI, perhaps to compare teams, then retrospectively re-estimating items after they're done seems almost irresistible. 

But both of these things, using velocity as some sort of KPI and re-estimating items after they're done, are both poor practices, in my opinion. 

Velocity isn't designed as KPI and different teams' velocities can't be compared. It's hard even comparing the current velocity of my team with their velocity from a few months ago. Changes to the team's composition and its definition of done can cause the apparent velocity to go up or down. [00:04:00] 

Daniel Vicanti's book, "When will it be done?", introduces more robust metrics for agile teams like cycle time and flow efficiency if you're ready to move beyond velocity for tracking your team's performance.

My teams don't re-estimate items after the fact. You're welcome to discuss it in your retrospectives and try it for a few sprints and see if it's a valuable practice for your team. But beware the dangers I've described above. 

The next question is from Jane, who asks, 

Jane: "If we don't complete a user story by the end of the sprint, should we re-estimate how much work is remaining and split the story points across the sprints in which the work got done?" 

Neil Benson: Thanks, Jane, appreciate your question. 

Some Scrum masters are horrified when they're scrum teams regularly overestimate how much work they can get done in a sprint and end up with incomplete stories at the end of the sprint. 

Listen, I don't think it's all that bad. When the sprint goal is ambitious, it keeps the team focused and, on our toes, and we find creative ways to meet the requirements with simple solutions. Of course, you don't wanna go too far and only manage to get half the sprint backlog complete in each sprint. But if there are one or two stories that don't get done, that's okay by me. 

I encourage my teams to keep user stories small. We should be able to get about 10 stories done in a sprint. Sometimes more, sometimes fewer. Depends on the size of the stories, of course. 

If there is a big story in the sprint, and for my team that would be an eight-point user story, we try and start it on day one of the sprint. Don't leave it until halfway through the sprint to get big stories started. If you don't complete some stories by the end of the sprint, there should be some of the small user stories, one- or two-point user stories. In this scenario, there's not a lot to be gained by splitting the story so that you can get some 'velocity credit' for the part that got done. 

Remember, tracking velocity is for the scrum team's benefit. If your annual performance [00:06:00] bonus is tied to your velocity, stop what you're doing. Thanks for playing. Try harder at Scrum next time. 

If your team started a big story, maybe 13 or even 20 points, and didn't complete it within the sprint, you might be tempted to split it. I might be tempted to split it. And count some of it is done and put the remainder back onto the product backlog for another sprint. 

But trying to split up a story when half of it is done is like hitting a big rock with a sledgehammer and hoping it'll split exactly where you expected it to. It rarely happens. You'll probably hit yourself on the foot with a sledgehammer. So put it down. 

The right time to split the story would've been before sprint planning. If it was sensible and possible to split that big story into two, and you chose not to by the start of the sprint, well that's something to noodle on as a scrum team during your next retrospective.

Again, this is one of those ideas that my teams have tried. Uh, but we ultimately didn't find them valuable. So I don't rush to recommend it to my new teams. But you're welcome to try it, experiment with it for a few sprints, and let me know if it works for your.

Our next question is from Naz. 

Naz: "Should we estimate user stories, or estimate TASKS instead?" 

Neil Benson: Years ago, Naz, I learned Scrum from Mike Cohn and his advice was to write most product backlog items as user stories and estimate those with user story points. Then during sprint planning, he recommended decomposing the user stories into tasks. They're called tasks in Azure DevOps, and I think they're called sub-tasks in JIRA.

And then he recommended estimating those tasks in hours. The total time of the estimated task hours should be equal to, or less than, the team's forecast capacity for the upcoming sprint. 

Some teams like having a Scrum board with user stories that stay pinned on the left, and it's the [00:08:00] tasks that progress through the columns from, to do, to done. Other teams like mine don't use tasks and we move our stories from the left to the right, through the, to do, to done columns.

There's a Scrum trainer from Melbourne, Brett Maytom, who says that when his teams do not use tasks there is: a lower focus, a lower sense of urgency, that progress is harder to identify, that human-to-human coordination goes up, that daily scrums become status meetings, people feel like they can't identify when others are blocked and need help, taking task ownership is harder. There's a feeling of vagueness feeling lost and overwhelmed, a lack of awareness, anxiety, and stress. 

Oh my goodness, Brett. Wow. 

My teams haven't used tasks for years and we've never had any of those feelings, but this is definitely one of those practices you could experiment with. Brett isn't involved in Microsoft Business Apps, but I know a lot of successful, agile business apps teams who use tasks and find it worthwhile.

But only a minority of the teams that use tasks go to the extra trouble of estimating effort at the task level. 

There's a risk that you start getting confused between estimating tasks in hours and estimating user stories in story points, and that your stakeholders will also get conflated between the two.

And there's a risk that all this extra busy work is for the benefit of a stakeholder who doesn't care about your business app as much as your product owner does. You're estimating tasks for the benefit of the PMO or somebody like. 

Thanks, Naz, I hope that helps. 

Our last question for this episode is from Dipesh.

Dipesh: Should our developers include the time spent in scrum events in their estimates? 

Neil Benson: Dipesh, it sounds like your developers are estimating their backlog items in units of time, either hours or days. And then wondering what to do with the time spent in scrum events. 

If [00:10:00] you're running a two-week sprint, your team will usually spend one to two days in scrum events. Probably closer to two days, if they're decomposing everything into tasks and then estimating those tasks. Takes a long time. 

If they then set stakeholder expectations that an item, I don't know, let's say it will take four days. There's a danger that the stakeholder expects the item to be done in four days' time. You've confused your stakeholder, uh, with elapsed time and duration.

You told them it would take four days, meaning it takes four days in duration and they thought you were going to start today and finish it before the end of the week, as in elapsed time. That's one downside to time-based estimates. 

But let's say you've helped your stakeholder understand the difference. And they now know that there's a difference between duration and elapsed time and that your estimates are always based on duration. The amount of time the work will take. 

The next assumption that they might mistakenly make is that, well, they know there's five developers in your scrum team, and they know that you work in two-week sprints. So, they'll assume your capacity should be 50 developer days. Now you've got to explain that your scrum events take two of those 10 days. Plus, there's time taken up by backlog refinement, and company meetings, and training time, and personal leave. 

Now you've got to try and explain your team has only got capacity for 32 developer days of work in each sprint. Not 50. Now it sounds like you all work part-time and your manager storms in and demands that you all pull yourselves together and start working your contracted hours. Maybe even work overtime to ensure your velocity stays at least 50 days per sprint. 

The lesson here is estimating in units of time will get you into all sorts of trouble.

 Your estimates should be for the risk-adjusted amount of effort it will take to get the work done. From there, you derive the duration taking into account that your developers will spend a day or two each sprint [00:12:00] in scrum events. 

Thanks to Tanika, Jane, Naz, and Dipesh for your questions.

 If you'd like to have your questions answered on a future episode, you can send me a message via LinkedIn or an email to amazingapps@customery.com. 

If you don't want me using a stock AI voice to read out your question, you can leave me an audio question and I'll use that in the podcast instead. Visit https://AmazingApps.Show and click on the Send Voicemail button that swings in from the right-hand side. 

That's it for episode 126, visit https://AmazingApps.Show/126 for show notes, transcript and resources. You'll find a link there where you can sign up for my Estimating Business Apps course. Like I said, it's free and the first three sections, uh, which has got a bunch of videos and some quizzes are all ready to go.

I've got a few more episodes planned on the topic of estimating your business apps. So, keep your questions coming and remember to subscribe. Until then, keep sprinting.