notes from a passionate developer

Developer that lives by the mantra "code is meant to be shared".




This is a personal blog. The opinions expressed here represent my own and not those of my employer, nor current or previous. All content is published "as is", without warranty of any kind and I don't take any responsibility and can't be liable for any claims, damages or other liabilities that might be caused by the content.

How I think sprint backlog prioritization can be a hinder

Daniel WertheimDaniel Wertheim

I once was at a session on a conference where the speaker talked about their view of how to become a great team and work effectively. There was one thing during this session that I really agree on and want to highlight, and that is the problems I see of working slavishly according to the prioritization of the sprint backlog.

First of all, lets be clear. I don’t talk about the prioritization of the product backlog now. I talk about the sprint backlog. And I do get, that if each task are prioritized by the business and we work from the top to the bottom in the sprint backlog, we will be delivering items as planned and requested by the business. How ever, if we can complete everything in the sprint, the prioritization has no value. Of course, if we would start working with the lowest prioritized item first and we don’t have the time to complete all the tasks, the customer will get the items in the wrong order. I do get this, how ever, the plan is to deliver ALL THE FEATURES REQUESTED IN THE SPRINT.

Now, lets also emphasize on the obvious. What I’m about to write might not be applicable on your team. But my issue with this “slavery model” is simply that I see a big risk of it killing creativity! By nature we all have different interests and we all prefer working with the items we are more interested in. My opinion is that allowing developers to work with the things they are more interested in, creates a better team. Why? Well, working with something you are interested about will give a more happy you and happy peers creates a better atmosphere. A better atmosphere increases the chance of getting a more productive team and most likely produce better results in the long run.

Sure you risk stuff, like having some people dodging “boring stuff” or dodging the stuff they “seem afraid off”. But that is something your peers and scrum master quite easily should pick up if he or she has any good skills in working with people.

I would also say that you have other simple factors to take into consideration when working with the sprint backlog prioritization. Like the “daily shape of you and your peers”. Everyone can have a mood swing or just be feeling down one day, and during this day that person might not be suited to work with the task lying there on top waiting for the next “resource” to become available. Note the word “resource“. That is exactly the feeling you risk of bringing to people if they are supposed to work like machines. “Take this”. “Do that”. “Because Foo Bar wants it”. Getting people to feel like resources, is not the spirit I would like to have in any team I would manage. And I do think you should reflect how you work with the prioritization of the items and how it affects your team.



Developer that lives by the mantra "code is meant to be shared".