Priorities and the Wise Developer
Guy Silva discusses how developers can harness their experience to help organize the backlog in their team’s sprint.
“Priorities do not necessarily represent the best (nor only) way to organize a sprint backlog.”
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?
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:
- 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).
- You have not one but two POs, each having one epic in the sprint.
- 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:
- Second epic starts too late and do not reach the deadline.
- Second PO does not see his tickets moving forward and start push for it to start.
- You got so frustrated with the messy ones and due to stress it causes the simple ones not to be as simple anymore. So, you end up taking way longer and not delivering many of those.
It doesn’t mean that it will always happen like that but there’s a huge possibility.
Prioritized VS Ordered
Problems like that occurred because the backlog was sorted using priority as a criteria. This isn’t wrong but is not optimal if used as the only criteria because it doesn’t 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 it is the 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 to be ordered not only by priority but to also account for other factors.
What to look for?
Few things to help you spot ways for improvement when ordering:
- Check for dependencies: items that need to be the foundation of something else need 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
With those concepts in mind, your sprint backlog should be way easier to handle.