Prioritizing Effectively as a Team


If you’ve ever worked on a development project, you know you can never be that sure that everything will be completed on deadline. By prioritizing actively, you can change success from something binary—either we make it or we don’t—into something more gradual. By doing this, you increase the chance of succeeding in delivering something. If you prioritize really well, that something may even turn out to be far more valuable than anything you penned down in your initial plan.

A common reaction to the product owner role is to see it as too big for a single person. If the idea were that one person should do everything from guiding the vision to writing user stories, I would agree. But that’s not how I see the role; I see it as one component in getting to effective teamwork.

A colleague of mine once came into the office reeking of frustration. He told me what had happened. Hoping to get some help, he had just spoken with his project manager about needing clearer priorities.

“Too much is going on right now,” my colleague had said. “We’re not getting anywhere—we’re just skidding around. If you could help us prioritize, that would really help.”

“Well,” the project manager said, “we don’t really need to prioritize because everything has to be done by March 31.”

I have to confess that my first thoughts about that project manager weren’t particularly nice. However, as I kept thinking about the absurdity of the answer, I found one way to understand the project manager’s perspective: If you know beyond a shadow of a doubt that everything will be done by March 31, then prioritization isn’t that important. After all, everything will be done, so why worry about the order of doing things?

If you’ve ever worked on a development project, you know that we can never be that sure that everything will be completed on deadline. You also know that there are many factors in organizations that push us to act as if we were that sure. Uncertainty, mildly put, is seldom a welcome state, so woe unto those who mention it.

Unfortunately, if you want to be agile, you have to not only mention uncertainty, but also engage with it head-on. Unlike the project manager in the story above, an agile product owner can never hide behind the answer “Everything has to be done.”

If you are even slightly worried that your cherished plan might not play out as desired, you need to do very active and continuous prioritization work. Good prioritization is what lets you ship by the deadline even though some stuff turned out much trickier than you expected it and half of the initial requirements have been swapped for something completely different.

By prioritizing actively, we can change success from something binary—either we make it or we don’t—into something more gradual. By doing this, we increase our chances of succeeding in delivering something. If we prioritize really well, that something may even turn out to be far more valuable than anything we had penned down in our initial plan.

In other words: In development work, prioritizing well is the key that lets us survive in spite of budgets, deadlines, and unknowns.

The challenge is that prioritizing is really difficult. Prioritization in an agile context means seeing both the bird’s-eye view of things and the nitty-gritty details as we discover them. In practice, this often means the task of prioritizing is too difficult to be done well by a single person. Here are just some of the skills needed:

  • Deep insight about the needs of the people on the receiving end
  • Understanding how the business works
  • Analytic thinking
  • An understanding of what is technically possible
  • The ability to learn rapidly in order to cover important knowledge gaps
  • Knowing what other constraints are in play

User Comments

Doug Shelton's picture


I think I understand and agree with your contention that the "team" (and by that, I'm assuming you mean the folks actually working on producing the product: developers, DBAas, QA, etc.) needs to help the PO articulate the requirements as they can bring in understanding of technical issues, dependencies, etc that the PO may not have.

However - I think you've gone "too far" on this line of thinking when you state "But in a just slightly more challenging product, it’s more helpful to see the product owner as someone who focuses on the overall direction, and the entire team as responsible for talking to customers and capturing those conversations as user stories." [bolding is mine].  

Why?  Developers already have their hands full., and I do not agree that they should expand into the realm of collecting requirements from other customers in an agile development environment.  Rather, I'd recommend that in such cases, the Product Management area needs to beef up its staffing and get more POs in the mix to do this work - and the team may need to be divided into multiple teams to collect and code those diferent requirements - OR - the other POs can feed the info into the Team's PO who continues to act as the one SPOC for the Team's requirements.  Having multiple people collect and feed requirements into a dev team - whether they are POs or Dev team members - is always confusing and often leads to arguments over priorities, etc., although I'd recommend that if this does happen, it should be POs and NOT developers, who have their own set of dev tasks to work on.

June 19, 2014 - 9:21pm
Tobias Fors's picture

Doug - thanks for commenting and sorry for not replying until now. Beefing up the product management area is one approach. The thoughts in this article come from my experiences over the years with organizations that have tried that approach and struggled with it.

The main problem I see clients struggle with is that of developing and spreading the knowledge needed to build a successful product or system. The approach with one party that prepares the work and one party that executes it is certainly the traditional and well-known one. I guess it doesn't have to happen, but I've seen this break down and become an inefficient relay race with ensuing finger pointing one too many times. That's why I often prefer to see full teams that take a shared responsibility for creating the knowledge needed for a successful product.

When it comes to confusing over priorities, I think that is a separate question. Priorities can be made clear and agreed upon even in a team environment where the full team (or a larger portion of it than usual) participates in the work of understanding the true needs of clients and users. We use mechanisms like shared planning sessions (as in Scrum) and visualization of ongoing work (as in Kanban) to make this happen. This makes it safe for more people to engage in the essential knowledge-creating conversations.

July 29, 2014 - 3:02am

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.