Priorities and the wise developer

The priority do not necessarily represents the best (nor only) way to organize the sprint backlog

Priorities blank list by Marco Verch under Creative Commons 2.0

So the team is about to start a new sprint with all the approved artifacts nicely prioritized by the Product Owner(PO). Each developer picks, obeying the priorities, the first unassigned artifact to work on and that continues until all is picked. By the end of sprint, most likely the leftovers, if any, are going to be the artifacts there were at bottom of the list, as they obeyed the prioritization PO is satisfied and everyone is happy.

Are all the sprints really like that? :D

Corner Situations

Yes, most of the time it works like that, hence the framework is so strong and heavily used. But hey, imagine these cases:

1. there are two epics to be delivered in this sprint and you know the second epic in the list needs more days of development (let’s say it needs a full regression test hence to stay few days with QA).
2. you have not one but two POs, each having one epic in the sprint.
3. you have too many dead simple artifacts by the end of the list and some messy ones by the top that you aren’t really sure if you will be able to deliver

For situations like those, is it really wise to obey strictly the priority on that list? Does the prioritization of the artifacts done by PO accounts for all those technicalities?

Some of the problems

Just so you understand possible outcomes, I’ll fast forward the scenarios to the end of the sprint:

1. second epic starts too late and do not reach the deadline
2. second PO do not sees his tickets moving forward and start push for it to start
3. you got so frustrated with the messy ones and due stress it causes the simple ones aren’t simple anymore and you ends up taking way longer and not delivering many of those

It is not as it will always happens like that but has huge possibility.

Prioritized VS Ordered

The problems like occurred because the backlog was sorted using priority as a criteria. Which isn’t wrong but is not optimal if used as the only criteria because it does not account account for the ROI of the development.

Having an item being handled before another may result in less overall development time than if they were handled in the opposite order, hence the ROI is not necessarily tied with the priority.

Although is a responsibility of PO to properly organize the backlog, I believe we as developers should bring our experience and be constantly alert of such sub optimal situations in order to help, at least, the sprint backlog be ordered not only by priority but to also account other factors.

What to look for?

Few things to help you spot a space for improvement when ordering:

Check for dependencies: items that needs to be the foundation of something else needs to go first. Not only obvious things but sometimes like fixing a particular bug before implementing a functionality saves a lot of time.

Check for consecutive big items: having a hard task just after another hard task may worn the dev due stress, perhaps having some small ones in between can help the morale as those will be easily achieved.

Check the objectives of the sprint: even ordered a list may not expose the concept of many objectives (like the case of two POs) by moving tasks from objectives up you may parallelize the start. So, instead of having all tasks from one epic then the tasks from another epic, leave tasks from both epics to the point that on the first round developers get assigned to something, both epics would start its development.

Check the skills from the ones that are going to implement: some times the execution will happen on a new project/language so you should also account that risk when ordering

I guess if you manage to apply those concepts your sprint backlog should be way easier to handle

All examples and situations are real live problems faced by the “Lannisters” team (who I’m part of) at Cover Wallet