Congrats on Your New Role!

So there you are, a brand new project manager (PM), or product owner (PO) and ... wait a minute. What the heck's the difference? In many agile projects, there is no project manager and the PM's responsibility is distributed across the various members of the team: product owner, developers, ScrumMaster (Scrum), Coach (XP), and so on. Thus, the definition of a PM is sometimes muddied and in my experience, varies wildly across organizations.

But because the waters are often muddied here, I‘m going to handwave this entire issue and hope you don‘t notice. Instead, we‘ll focus on an age-old problem in the PM/PO space: what should we do next?

So ...

What Should We Do Next?

As a fledgling team lead, PO, PM, or whatever title your company‘s uses for person responsibile for getting stuff done, figuring out what to work on next is a daunting task. It involves having an in-depth knowledge of the project, the product, the business, and the team. And when you're juggling 27 things at once, it can be maddening to have a bunch of baby bird cheeping "what do I do next?", demanding you vomit up user stories for them to work on.

You might think that backlog grooming/refinement is all you need, but that still doesn't tell you, out of the 374 tasks that need to be done, which should be done next. Fortunately, there's a very simple way to do this, and that's to build a business case for each task, using just three numbers.

The Three Number Business Case

A business case is really nothing more than making an argument that a thing should or should not be done, but using numbers to back it up. If you want to learn more, I have a "rescuing a legacy codebase" talk that covers this.

But what numbers do we use? For this case, try to pick the three most important numbers that represent value in your tasks. At one point, when I had the project management role in developing Tau Station, a free-to-play (F2P) narrative sci-fi adventure, the complexity of the role was overwhelming, but each task's "three most important numbers" were clear: complexity, usability, monetization.

The complexity of a task is simply how many "story points" (or whatever you call them) that team members have assigned to a task. I recommend using Fibonacci numbers for story point estimates, especially for what I'm about to show you.

The usability of a task was how useful it was to the customers. Again, you want to use Fibonacci numbers here. You need a feel for what this number is because, in reality, you cannot get a perfect estimate. However, it's clear that a feature which lets customers download reports is more valuable to them than a feature which slightly adjusts the color of a sidebar, so the former might get the number "13" while the latter might get the number "1".

In the case of Tau Station, everyone is allowed to play the game for free, but as with many F2P games, there are monetization options in the game and things which increase the likelihood of monetization gets a higher number. A "Happy Hour" feature, where the players get extra rewards when they buy stuff gets a higher monetization number than a feature to make forum posts "sticky." Again, you're using Fibonacci numbers here.

Important: the three things you choose should reflect your business concerns and may very well be vastly different business requirements. You may choose "security" or "legal compliance" or something else entirely. Tau Station included these as part of the "usability" number. Think hard about these numbers because you don't want to get them wrong.

Once you have your three numbers, what next? Well, you need to assign weights to them. This will largely be a process of trial and error until it feels right. In our case, let's say that both monetization and complexity get a weight of 40 and usability gets a 20. Then you play around with formulae until you get a final score, with higher-scoring tasks having a greater priority. Here's the formula I used for Tau Station, though you will need to adjust this for your own needs:

pros  = monetization * 40 + usability * 20
cons  = complexity * 40
scale = 10
score = ( ( pros – cons ) + 500 ) / scale

Let's say a task has a monetization of 1, and a usability of 5, and a complexity of 7. How does that compare with a take of a monetization of 3, a usability of 3, but a complexity of 13? The first task might earn us less money and be less useful, but it's easy to implement. Decisions, decisions ...

Well, monetization and usability are both "pros" (benefits), and complexity is a "con" (drawback), so we have task 1:

pros  = 1 * 40 + 5 * 20
cons  = 7 * 40
scale = 10
score = ( ( 140 – 280 ) + 500 ) / 10

And task 2:

pros  = 3 * 40 + 3 * 40
cons  = 13 * 40
scale = 10
score = ( ( 240 – 520 ) + 500 ) / 10

Task 1 has a final score of 36, while task 2 has a final score of 22. Thus, we do task 1 first.

Once you learn to plug those three numbers into a spreadsheet, you can then sort the tasks by score and prioritize tasks at the top of the list.

Real World Usage

When I was doing this, I found it made my work much easier and the team appreciated it because it was clear direction. Plus, since the team provides the complexity estimates, they know that they have a real impact on project direction, something that teams usually appreciate.

I used an Excel spreadsheet, but also a small program that I wrote which fetched data from github and ZenHub to automate the creation of my spreadsheet. Every month I'd repeat the process, fill in missing numbers, sort the rows and share it with the team via a Google Doc. It worked very well and figuring out the project tasks for the month was no longer a stressful affair..

Note that sometimes you will find tasks which don't seem to be scored correctly with this technique. When that happens, investigate whether or not your three numbers seem reasonable. Maybe your weights are wrong, or your formula is off.

Or, as sometimes happens, there are external factors. A task may be complex, offer low usability, and no monetization potential, but another team is demanding that XML feed now and hey, you have to play nice with others. When odd events like that happen, use your judgment instead of your spreadsheet.

At the end of the day, this technique, like all others, isn't perfect. When used correctly, however, it's a great tool for building value and focusing on your real needs. Further, you prioritize greater value and, when asked to justify your decisions, you have numbers to back them up. Even if they're not perfect, quibbling over numbers and formulae instead of hunches is a much safer career move.