Competing Priorities from a Team and Business Perspective
We [the Agile community] value transparency and prioritization among many other things. We prioritize (or order) the most important things or the riskiest things to work on first. This is not new. What happens when it all is important or is all very risky or there is lack of clarity between the business and the team? Who has the final say in the priority of work items?
One of my teams made a comment the other day regarding the business prioritization of some epics and stories and how they were doing things in an order that didn’t make sense. This really made me think. Yes, our Product Owners and the business should have the first say in what is the most important, but they should be constantly working with the team to determine what is feasible and what is the logical technical order to do something in. If something technically needs to be done first to implement a key feature, then it should be done first otherwise it may lead to more re-work and unnecessary delays in release.
What it came down to was one main theme: a lack of communication or understanding between the Agile team and the business/product managers/BA’s/Product Owner regarding priorities discovered late in the cycle.
One of the tasks we do in backlog grooming/refinement is prioritization. But sometimes by the time we get to this ceremony we are looking at things on a too granular level. The epics and features have been decomposed into stories and ordered by the business. Without the team’s input (or the Product Owner’s technical understanding to give input) when these features are being ordered, things may not end up in an order that makes sense for development. That’s not to say it’s too late to change the direction, but if this isn’t noticed until the middle of a release the Agile team may be less inclined to say something directly in fear of changing the release scope that should have been defined and agreed on earlier, with an amount of technical certainty. That brings me back to shorter releases and feedback loops, but I digress. Let’s take a closer look.
When the team isn’t included earlier (or at least a knowledgeable representative of the technical limitations and implications; PO, tech lead, ScrumMaster) it can cause priority problems down the road. Things may be developed out of logical order which can cause development and testing nightmares and unnecessary re-work. This is where the ScrumMaster should come in and work with the team, Product Owner, and other business folks to maintain transparency about what should be built in what order and any other dependencies that may need to be addressed from both a business and technical perspective. This does not have to be from a technical perspective, the team can do that, but more from a facilitation perspective to ask the right questions and get the conversation moving.
In making prioritizing a priority at all levels, I encourage as much transparency as possible between business priorities and technical dependencies. This will help ensure the business and customer is getting what they want in the most timely manner and the team is doing things sequentially with more accurate testing and less re-work. I’m not advocating over-planning vs. adapting to change, just merely stating the right people need to be communicating at the right time to avoid unnecessary re-work and re-planning. This should not be a one and done conversation but ongoing at various stages of feature decomposition and backlog refinement; we’re agile after all. The final say in prioritization should go to the business but not without due consideration and knowledge of the technical work that accompanies it.