Prioritizing Effectively as a Team

[article]
Summary:
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

1 comment
Doug Shelton's picture

Tobias:

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

About the author

Tobias Fors's picture Tobias Fors

Tobias Fors works as a management consultant to software developing organizations. By combining his experiences from working in different roles in software development (since 1999) with a dose of common sense and some tricks of the trade, he helps other people succeed in software development. For more articles from Tobias, see tobiasfors.se, citerus.se, and @tofo on Twitter.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 22
Sep 24
Oct 12
Nov 09