Should You Assign Stories to Developers in Sprint Planning?

[00:00:00] Should we assign items to a developer during sprint planning? Some of my scrum teams building Dynamics 365 and Power Platform applications assign sprint backlog items to a named developer during the sprint planning event. Is that a good idea or not? That's the question we're going to be answering in this episode of Amazing Applications.

 Hey, welcome back to the Amazing Apps podcast. This is your host, Neil Benson. 

Just before we get started, I wanted to congratulate a few business apps makers who have recently achieved their Professional Scrum Master 1 certification with Scrum.Org. Well done, Temmy Wahyu Raharjo, a new Microsoft MVP from Malaysia, Josh Reeves at Preact in Newcastle in the UK, and Tina Jensen, at Donkey Power in Denmark. Congratulations to all of you and to everyone else who has completed a Customery Academy course recently. 

 My current team is building a Dynamics 365 Customer Service application for a state government to manage the participants in the state's new drink driving program. It's a program you end up being a member of if you've been found guilty of a moderate or serious drink driving offense, or are a repeat offender. It's the membership club the government doesn't want anyone to be a member of and no one wants to join. In fact, everyone in Queensland will be happier and safer if our Dynamics 365 app has got no customers in it. 

The same [00:02:00] team, or the same developers, built a membership application for another organization in our state. It was a roadside assistance club that also offered insurance and banking services. They had nearly 3 million members in their Dynamics 365 database, including thousands who had been members for over 50 years.

It's the same team, but one of our practices has changed. 

Previously in our sprint planning event, every two weeks, we used to assign backlog items, usually user stories, from the upcoming sprint to a named developer. Often we'd walk down through the items on the left-hand side of the board, and one of the developers would volunteer to work on the card.

It was a quick exercise. If we had 20 items in our sprint backlog, it would take us a couple of minutes. We found this exercise useful because at the end of it, we would know who is going to be working on what and how evenly the work was distributed. We could compare the distribution of work to each developer's declared capacity for the upcoming sprint.

"Hey Sapan, how come you've got more story points of work assigned to you this sprint compared to the last sprint, but you're going on leave all of next week?" 

Those kinds of capacity questions helped ensure we had the appropriate distribution of work planned for the upcoming sprint. Assigning items to developers in sprint planning seemed like a good idea. 

But we don't work like that anymore. Let me tell you what we do instead, and why. 

On our latest project to build the app managing the drink driving members, we don't assign items during sprint planning. Instead, all the items in the To Do column are assigned to Danish. He's the developer in our team who is our primary business analyst. He owns almost all the To Do stories because he's the developer who helped the product owner elaborate and refine them.

Then when one of the other developers has capacity, they pick up a story from the To Do column and assign it to themselves. And until that [00:04:00] moment, the team doesn't know, and doesn't have a plan for, who is going to be working on that specific item. The developer who picks it up might be a low code developer who extends the data model and configures the form and maybe a flow, but it needs a plugin.

So the low coder will find a pro code developer who will assign it to themselves. Next, another developer will assign this story to themselves to perform a peer review, and then another developer will assign it to themselves and perform a functional system test on the feature. Finally, yet another developer will assign it to themselves for an acceptance review with the product owner and now the item can be declared done. 

By the time a typical user story is done in one of our sprints, it will have been owned by four or five developers over its lifetime. And that's out of a team of six. Almost everyone in the team makes a contribution to all of the users stories. 

As Ryan Cunningham at Microsoft says, building business applications is a multiplayer game.

My team's current experience is certainly bearing that out. What we're finding is that a story isn't done by one person, it's a collaborative team sport. Almost everyone in the team works on the story at some point. There are lots of comments and interactions in our Microsoft Teams channel as we pass the story around during the sprint, getting it from To Do over to Done.

Did you know that the name for the Scrum framework was inspired by an article in Harvard Business Review from 1986? It was by Hirotaka Takeuchi and Ikujiro Nonaka and it was called "The New New Product Development Game". In the opening paragraph, they write, "...companies are using a holistic method, as in rugby, where the ball gets passed within the team, as it moves as a unit up the field."

In their paper, Takeuchi and Nonaka contrast the traditional, sequential style of product development as a relay race [00:06:00] where the product is passed, like a baton, from one group of functional specialists to another, from phase to phase, starting with concept development and on to final production. 

Instead, they noticed companies like Honda and 3M using a holistic "rugby" approach where a multidisciplinary team tries to go the distance as a unit, passing the ball back and forth. Here we are, 35 years later, working in a similar way today. Building business applications in our fusion teams. 

Getting back to our original question then, should we assign items to a developer during sprint planning? I don't think it's a terrible practice. You might find like we did that it helped with capacity planning.

But if that assignment is rigid and inflexible, if your team discourages stories from being passed between the players and your team, if you notice that the assignment discourages collaboration and only the assigned developer works on the story, then you're playing a single player game. You're missing out on the benefits of a multiplayer, multidisciplined, fusion team.

Here's your action to take away. Discuss item assignment at your next sprint review. Take a look at your data on how stories have been passed around, or not, in the last couple of sprints and trying to pass them around more in the upcoming sprints. 

I think you'll have more fun. You'll improve your collaboration. You'll increase your quality and your team will have a better understanding of all of your application instead of one or two individuals, having all the expertise in certain features. 

If you'd like to ask a question about adopting agile frameworks in your Microsoft business applications team, you can reach me at neil@customery.com or leave a voicemail https://speakpipe.com/customery.

Thanks for joining me. I really appreciate you listening and remember, keep sprinting. G'day business apps builders. I hope you enjoyed this episode. Hey, before you go, I wanted to share with you an important [00:08:00] insight and share something I made just for you. After spending thousands of hours coaching teams from all over the globe, I've learned one big lesson: everyone who wants to use an agile approach to build business applications has a different definition of what Agile is. 

If you're a business apps maker getting started in your agile journey, then it's worth understanding what Agile really means. 

Where did agile approaches come from? 

What are the benefits for Microsoft partners and customers? 

And how can you get started and certified and the most popular agile framework of them all? 

So I put together a short, action-packed foundations course that reveals why traditional approaches to software development don't work for low code, no code business applications.

 You'll learn about the agile manifesto and the history of agile practices, the benefits of an agile approach for your applications. And you'll learn about the Scrum framework and how you achieve your Scrum certification. 

All in less time that it takes you to spin up a new Dynamics 365 trial environment.

It's been said that only a fool learns from their own mistakes, but a wise person learns from the mistakes of others. This is your opportunity to benefit from all the mistakes I've made, figuring out what doesn't work in order to identify what does. 

If you're ready to get beyond listening and to start being, consider this training your bat signal. 

To gain instant access for free, visit https://customery.com/foundations.