A very frustrating problem for any engineering team is shifting priorities. Having to switch context on work items is a sure way to introduce delay, slowing a teams productivity and causing plenty of frustration.
Sometimes organizations have to shift requirements. For example, a critical customer issue or a pending sales opportunity comes up. But ideally, once a sprint is set, the priorities are set in stone and the scrum team can stay focused. However, companies that do shift priorities often have a few common problems.
A common issue is that too many people are setting or delivering priorities. When stakeholders and managers interact with engineers directly, it’s all too easy for them to influence the priority of the work. You’ve heard things like, “Jack from sales said he needed this asap for a customer demo”. Both the scrum team and your stakeholders should know that priority comes from one source – the Product Owner.
It’s the Product Owners difficult job to manage the expectations of the other stakeholders and deliver the correct priority message, so that engineers are not constantly shifting gears and contexts. If Product Owners find themselves on a team that supports the “loudest voice” or most urgent item they need to sit down and have some serious discussions to resolve it.
A few things to remember:
- Priority, as shifty as it may be, needs to come from the Product Owner
- Shifting priorities usually leads to features that are not completed on time, as the new work sacrifices the original work
- Usage of resources should be aligned with the overall business goals not any one voice
- There needs to be a plan to handle true cases when priorities for a Sprint must change
- To optimize an engineers productivity, give them uninterrupted focus and they will do their best work!
Work-Agile 