Definition of Next
In this episode, we're talking about what's next as a developer working in a scrum team. How do you know what to work on next when you've just completed a product backlog item?
This article and my t-shirt are inspired by my favourite TV series of all time, The West Wing. In The West Wing, fictional U.S. President, Jed Bartlet, and his advisers steer the country through some turbulent times (without using Twitter). The show first aired 20 years ago in September 1999. And it's amazing how many of the plot lines are being repeated in the White House, but with very different presidential behavior. There are several times in the show where President Bartlet has finished with a topic and is ready to move on. So he'll ask his staff, "What's next?". That is their cue that the President is ready to move forward. His catchphrase has also become the catchphrase for the West Wing Weekly podcast show, where Hrishikesh Hirway and Joshua Malina break down a West Wing episode each week in their podcast. West Wing Weekly is my favourite podcast. And if anyone out there has got a spare ticket for the recording of the final episode in Los Angeles in January, I'll donate a thousand dollars to your nominated charity and see you there.
Getting back to what's next for our developers in our scrum team. Imagine this scenario, you've just finished configuring a flow that gets triggered every year to check on the renewal status of an agreement. In Azure DevOps, the card has been picked up by another developer for testing. And remember in Scrum, in the development team, everyone is a developer. We might have different specialisms like analysis or configuration, you know, actual coding or testing. But we don't have titles within the development team. We're all developers. What do you work on next?
My Team’s Definition of Next
Scrum teams should consider a definition of next. Just like you have a definition of done and many teams have a definition of ready, a definition of next guides developers who are looking for an item to work on.
1. Work on another user story
That's the top priority. Assign an unassigned user story in the backlog to yourself and start working on it. We start working on a story by grabbing the product owner or an analyst and a tester and discussing the items details so that everyone's got a shared understanding of it. Some teams call out the 'Three Amigos' discussion. It doesn't have to take an hour. The item should already meet your definition of ready. So the conversation should only take a few minutes and then you can get started. A short discussion beats the reading detailed acceptance criteria every time. Should you prioritize a large story that has a big estimate or a small story with a lower estimate? Well, to me, that depends on how far you are through the sprint. If you're near the start, grab a big story. If you're near the end, grab a small one. And if you're in the middle. Check with your team and your scrum master. Ask them whether it's worth starting a story that you might not be able to finish yourself before the end of the sprint. If there are no more unassigned stories to work on, what's next?
2. Get all your stories done
That's number two. If there aren't any unassigned stories in your sprint backlog, it means that every item is in progress with another developer. Ask them if any of them need a hand or can assign a user story to you. Scrum is a team sport and it's your job to help the team reach the sprint goal and achieve the project's outcomes. Your teams should have an agreed definition of done with criteria such as unit tests or documentation, having a deployable solution, creating screenshots or user videos or whatever. All the items need to meet your definition of done. It's not uncommon to wait until testing is complete or for your users to have reviewed the feature before the item is considered complete, and then you've got to finish it by meeting the definition of done. If there's no unassigned items to work on, then make sure all your items meet the definition of done. And if all your items are done, then what can you do to help your team achieve their definition of done for their user stories? Can you write their unit tests or documentation? Can you perform a code review or write up the feature preview with a user? Remember, if items don't meet their definition of done, then are not considered complete and they might spill over into the next sprint. And that's bad news for you and the team. So get your definition of done. Done. Okay. What's next?
3. Complete a spike
If there are no more unassigned stories and your definition of done are all done, what's next? Your team might have spikes, defects or chores. Next, my current team starts on spikes. A spike is a time-boxed research item such as an investigation and evaluation or a prototype. Spikes reduce risk by uncovering requirements, assessing options or weighing up a design. We don't always have spikes and every sprint and we rarely have very many. Sometimes a spike can have a higher priority than user stories. This can happen if another team is dependent on the outcome of our spike or if we must deliver stories in the next sprint based on the outcome of the spikes in this sprint. And we need sufficient time to refine those new stories. But normally we prioritize spikes after user stories. If there are no more unassigned user stories, all the other stories are done. and there aren't any spikes in the sprint backlog, what's next?
4. Resolve a critical or high severity defect
You could prioritize defects next. I recommend that you fix defects within the sprint that you detect them. Don't waste your effort documenting them. Just walk up to the developer who last worked on the feature and help them fix it. But if your defect has been reported by user maybe in production or by regression testing against an earlier increment, then it should be captured in your product backlog. Our product owner prioritizes defects, and so any critical or high severity defects are next. We don't work on medium or low severity defects unless there's a good reason the product owner prioritizes these ahead of user stories. OK. So there are no more critical or high severity defects in the product backlog. What's next? Don't worry, there's still plenty of work for your development team to do.
5. Do a chore
6. Work on a story in the product backlog
I recommend that you look at the top of the product backlog for a small story. I would assign it to myself and start work on it, but I wouldn't necessarily bring it into the sprint backlog unless I've checked with the rest of the development team that we think we can get it done before the end of the sprint. If we can't get it done, then you could still start work on it without moving it into the sprint. There is a risk, however, that even though it's at the top of the product backlog, that the product owner might not want us to work on it in the next sprint. So I'd check with my scrum master and product owner first before starting that kind of work. If your product owner isn't ready to start work on any other user stories, then what's next?
7. Resolve a medium or low severity defect
Are there any medium or low severity defects that relate to any of the features we've worked on in the current sprint? I'd bring one of those into the current sprint and work on it. It's usually late in the sprint by the time you're looking for a medium or low severity defect to work on. Again, double check with the other developers, the scrum master and your product owner to make sure there's nothing else higher priority in your definition of next that you could help with. Especially towards the end of the sprint where things can change from one hour to the next as your team sprints towards the line.
8. Refine your product backlog
If you're following along, this is #8. Finally, as if by some miracle your team has met its sprint goal, got all its forecast stories done, completed all the spikes, chores and defects available, and you're not ready to start work on any other items in the backlog. Then the last priority in our definition of next is to review and refine any items in the product backlog. Can you split any of the upcoming user stories? Can you improve any of the acceptance criteria? Have you estimated all of the items that your team could work on in the next three, four or five sprints? If you have, well done. But the truth really is that no team ever has the capacity to do all of that.
9. Read the Microsoft Business Applications Licensing Guide
If you still have spare capacity you should sit back and -- I don't know -- memorise the latest editions of the Licensing Guides for Dynamics 365, PowerApps and Flow and PowerBI, . That'll suck up whatever time you have remaining. Good luck. Keep sprinting!