Sprint Goals for Microsoft Business Apps

Neil Benson: [00:00:00] If you can write your sprint goal in the subject line of the sprint review invitation to your stakeholders, and they stampede to accept your invite and beat down the door at sprint review, that's a great sprint goal. 

This is Amazing Applications. Hi, it's Neil Benson here. Welcome to Amazing Applications where we wanna help you build amazing. Agile Dynamics 365 and Power Platform applications that everyone will love. 

This is episode 123, and we're talking about how to use sprint goals for your business applications. You'll find show notes on a transcript at https://AmazingApps.Show/123. 

I have to confess, I struggled when I started using Scrum for my Dynamics CRM projects, back in 2008. I struggled using sprint goals. Over time, since then, I've learned that my team's work so much better, where we have good sprint goals and we can build better business applications when we use sprint goals.

So let's start with why sprint goals are a good idea in the first place. What's the benefit for having a good sprint goal? 

Our sprint backlog is emergent, just like our product backlog. We don't define everything up front. Even in sprint planning, we don't cram every minute of our sprint full of sprint backlog items. We have to leave room to uncover new knowledge that might tweak our sprint backlog during the course of the sprint. We're using Scrum to build complex business applications and we can't plan a project perfectly, and we can't plan a sprint perfectly either. 

The sprint goal gives the team a unifying focus without being prescriptive about exactly how we're gonna get there. It gives them a target, but our plan is flexible because designs will emerge as we begin to build increments. The sprint goal describes the value that we as developers are committed to delivering within the next couple of weeks. 

[00:02:00] Sprint goals give our scrum team an excuse to collaborate. When there is a sprint goal that the team is working on, developers will be working together on sprint backlog items to get them done.

And what I mean by that is we're not just handing one sprint backlog item to a developer and saying, "Hey, get this one done". We are working on it together. There might be two or three of the developers in the team working on the same sprint backlog item during the course of the sprint.

If you don't have a sprint goal, or you have a sprint goal with lots of sub goals and sub goals, you know, have conjunctions with and this and, and that, or you get commas or semicolons or a set of bullet pointed sprint goals with story IDs in them, then that's a bad sign. 

Your scrum team might be cooperating during the sprint without actually collaborating. Cooperating means that developers are each doing their own work. And try not to get in the way of anyone else. That's not really collaboration at all. That's the difference between everyone driving to work on their own, compared to sharing a bus ride together. Are you all on the same bus?

Writing a good sprint goal

The sprint goal emerges in sprint planning. That's the event where the sprint goal happens. Often, in my projects, the product owner has got a draft sprint goal that she brings along to sprint planning with her. 

Some product owners even have a sprint goal in mind for all the future sprints we've got planned. Those plans could change at any time. They're not set in stone, but they form a roadmap for our application. 

I love it when the product owner suggests a sprint goal that the developers can build on, they can question, they can support it, and then they can negotiate it. I think the best sprint goals are negotiable because the developers usually have more knowledge about what it takes to achieve the sprint goal than the product owner usually has. If it's non-negotiable, that's not a great sign of an empowered team. 

A good sprint goal makes sense to our stakeholders. It should [00:04:00] be meaningful and valuable to them. A sprint goal about APIs or integrations or something technical won't do that. If your stakeholders don't turn up to your sprint review, that's an indicator your sprint goal might have been vague or uninspiring. 

I don't like to write technical sprint goals that require Power Platform knowledge to understand. 

If you can write your sprint goal in the subject line of the sprint review invitation to your stakeholders, and they stampede to accept your invite and beat down the door at sprint review, that's a great sprint goal.

A good sprint goal has a clear link to the product goal. The product goal is a medium or long term goal for our application. For example, it's the theme of our next production release. 

You can totally take one feature- or epic-sized requirement from your product backlog and focus on it in this sprint. Choosing one feature makes a great foundation for a sprint goal. It just needs to be wordsmithed in such a way that it's valuable for our stakeholders and meaningful for our team. 

You might have a feature called 'Portal authentication'. You could turn that into a sprint goal, like 'External users will be able to log into our portal using their Facebook, Google, or Microsoft Account credentials.'

In that portal authentication example, the team might not be able to meet all the requirements of that feature within one sprint. Perhaps including Twitter and LinkedIn authentication were too much to include. Or two-factor authentication is needed as well, but it'll have to be left on the product backlog until a later sprint.

'Receive spare parts' might be the name of a feature or epic you wanna build for your field service technicians. When they visit a customer's home, the technician might need some spare parts that they don't have available in their truck. And they wanna find out the closest truck or depot that carries those spare parts, and then they can either arrange collection by the technician themselves or delivery to the customer's house by someone else. Ideally, while the technician is still at the customer's home. 

That's a lot to build in one sprint. [00:06:00] Way too much for our team to get done in the next two weeks.

Let's break that down and have a sprint goal to 'Enable field technicians, to find and reserve spare parts from the bin closer to the customer'. Getting the spare parts, either by collection or delivery, adding those parts to the customer's order and invoice, will have to wait until later. Our goal is just to reserve the spare parts from the nearest location. 

That might involve stories related to integrating Field Service with Business Central, searching for inventory and being able to return the distance from the customer in those search results. And it might involve building a feature to reserve inventory from a bin for a few hours. That's gonna take most of the team's capacity this sprint, leaving them with just a couple of unrelated user stories as sprint backlog items that relate to different features. 

Here are some ways I love to use the sprint goal.

First one is probably to communicate what we're doing to our stakeholders. I don't show our stakeholders our sprint backlog, which is usually a list of 10 or 20 sprint backlog items that we're managing in Azure DevOps that we're gonna be working on over the next couple of weeks.

Instead, after sprint planning, we can communicate our commitment to our stakeholders by letting them know the sprint goal that we have agreed, and that they can review that at our next sprint review. For example, at the sprint review in two weeks, you'll be able to review our progress towards generating documents triggered by events captured in Dynamics 365. Or, our sprint goal for sprint 17 is enable contractors to apply online for a road closure permit and have it approved within two hours. Join us next Wednesday to assess our progress and provide your feedback on this feature and what we should work on next. 

So those are some examples of how we can use sprint goals to communicate with our stakeholders. 

The second is to give our developers focus during our daily scrums and in their daily work.

Our sprint goal is road closure permits in two hours. Here's what I achieved yesterday that contributed to the sprint [00:08:00] goal. And here's what I'm planning to achieve today. That's the kind of focus we can have in our daily scrums. 

When we finish a sprint backlog item, and we're wondering which one to pick up next, we can check our sprint goal. Which of the to-do items contributes most towards the sprint goal? That's the one I'm gonna pick up and work on next. 

Not every sprint backlog item will contribute directly to the sprint goal. I love a sprint backlog where most of the sprint backlog items support the sprint goal somehow, but not all of them will. If less than half the items relate to the sprint goal, then perhaps we've got a problem focusing on the next most valuable thing.

The third way we can use sprint goals is in our sprint review. The sprint goal is the tent pole for our sprint review agenda. At the start of the sprint review, we remind our stakeholders what the sprint goal was for the sprint. Then we describe how far we got achieving that sprint goal. Hopefully, we achieved it 100%. If we didn't achieve it, here's what we didn't get done, here's why, and what we learned. 

The sprint review is an opportunity for the product owner to ask the stakeholders for their ideas, for goals for the next sprint or two. This is their chance to lobby for what they want our application to be able to do for them.

If your team likes to demonstrate the increments you've built, and most of us do, then the demo should focus on the features that support the sprint goal we've just achieved. I probably wouldn't bother demonstrating other increments that didn't directly support the sprint goal, unless a stakeholder asked me to.

Let's close out this episode with a couple of sprint goal questions that commonly come up. 

Emily: " Can we have more than one sprint goal?"

Neil Benson: Short answer is no. 

I worked with a team that was building an application used by two divisions in an organization. And each division's vice president wanted us to work on a sprint goal, focused on their division. We couldn't do it. You can't have two product owners and you shouldn't have two sprint goals. 

A better option would be to have two small teams working on [00:10:00] two product backlogs, each with a product owner representing one division's stakeholders, and each with separate sprint goals every sprint. And then you would use some scaling practices to coordinate the work of the two teams that are both working within a single environment.

Nicholas: " How do we create a sprint goal when we have lots of different, unrelated, high priority items?" 

Neil Benson: If your developers are working on many different, unrelated product backlog items, then you probably don't need a sprint goal. And the reason that you don't need a sprint goal is Scrum is probably a poor choice. You might not even need sprints. 

When I hear this question, it's often a group of developers who sit close together or who sit within the same department, but they're not acting as a team. A team works towards a common goal. And if you're all working on different things, then you're not acting as a team. 

An approach like Kanban might be a better way of managing your work, if you wanna use an agile approach. 

I think Scrum is great when you have a team building a complex business application, but not for handling bugs and enhancements in a support environment that maintains a lot of applications or development group building a portfolio of small unrelated business apps.

And the last frequently asked question about sprint goals is:

Don: " How do you determine the sprint goal when each sprint may have different sets of stories that is not related to one specific enhancement or feature? 

Neil Benson: I'm going to assume that you have a scrum team building a single business application. And unlike the situation in the previous question, you're not just a group of developers working on a set of completely unrelated items. 

Instead you have a product backlog for one application, but the high priority items near the top of it are somewhat unrelated. In this situation, I'd encourage you to work with your product owner to take the highest priority item and make that one, the focus of the sprint by crafting a sprint goal around it.

Scan your eyes further down the backlog and find any other backlog items related to the same module, the same component, or feature, and see if there's value on working on all those items together, [00:12:00] as a team, while working on that one, really high value item. 

If together those items make up at least half your developer's capacity, maybe even 70 or 80% ideally, then I'd try that. 

It's okay for some items in the sprint backlog to be unrelated to your sprint goal. Not too many, though. If less than half the team's capacity is spent collaborating on the sprint goal, then that's something I'd encourage you to examine in your next retrospective.

Okay. That's it for episode 123 on sprint goals for Dynamics 365 and Power Platform applications. I'd love to hear your sprint goals and give you some feedback or answer your questions. You can ask them on LinkedIn, wherever you see this episode posted. 

Until next time, keep sprinting.