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.
agile agile team business competing priorities compromise importance order prioritization priority product owner scrum scrum team scrummaster tech lead technical
5 Responses
Natalie,
Thanks for the post. The key thing I got out of it is the need for continuous collaboration and transparency more so than prescriptive prioritization processes (the alliteration was partially on accident.)
In other words, to make agile effective, you need to have continuous “adult conversations”.
Exactly, continuous adult conversations are key! Thanks for the comment, Kent!
Natalie,
I would love to have an engaged customer. We struggle more with trying to get their input more than we do with anything else. It’s as if we were hired to do a job but some how we have to figure out what to do. What order to do it in. Yet somehow we are responsible for when we get the order wrong.
This happens way too often. It normally goes like this. We are having a review and demonstrating a new feature. “Figurehead” says, “Who told you to do that?”.
So often we are left without direction. We build the backlog. We groom it. Plan sprints. Not a single customer shows. So we decided to put together documents to convey our plans and/or questions? *crickets* It’s a common for us to remind them that we still haven’t gotten their responses. Eventually we “have to” make the decisions ourselves, in the interest of the project.
I know this is not exactly the opposite of what your post was about but I would love to see a post or hear your thoughts on how to deal with a disengaged/uninterested customer. I can’t believe that our project problem is so unique.
Thanks again and keep up the good work.
Hi Jeff – great post idea. I will put it in my post idea backlog and think about some of the things that have worked to keep the customer engaged. Thanks for the comment and good luck with that! It’s a tough situation, but keep trying!
This aligns nicely with the concept of creating “possible/valuable/viable” conversations at all points of product development. We want to make sure people who can determine that we have the capability and capacity (possible), the value (to us and our customers), and the viable (technical feasibility) are having continuous conversations from the time an idea is conceived to the time we’re implementing the software.