Order out of Chaos

Putting your Product Backlog in order – what should you work on first?

Suppose you’re a Product Owner and you have a few items in your Product Backlog. How would you advise the Development Team on what to start working on first? Should you even care at all? What difference would it make if you were a bit deliberate about the order in which work items get tackled?

The tale of the two leaky barrels

To explore answers to these questions, let’s consider the story of two leaky barrels. Imagine we run a bar and have two troublesome barrels. One holds whisky, the other holds beer. Both are leaking right now, losing us money. Every minute that passes, we loose about $50 worth of whisky and $10 worth of beer.

Based on this information, which one should we fix first? A natural impulse would be to start working on the whiskey barrel. After all, we’re losing five times as much money each minute from it. So far, so good.

Imagine that we resist that temptation briefly enough to get curious about how long it would take to repair the barrels. Let’s further suppose that our investigation turns out that it would take a minute to fix the beer barrel and about ten minutes to fix the whiskey barrel. Armed with this new information, is it still a safe bet to fix the whiskey barrel first? Oops. Not so much anymore.

Sure, in the minute we’d take to fix the beer barrel, we’d lose $50 worth of whiskey. But if we took the ten minutes to fix the whiskey barrel, we’d lose $100 worth of beer. Ouch.

Cost of Delay or Speed to Value?

We can think of the $10/minute beer loss as a cost of delay (see Don Reinertsen’s work). Seen from this perspective, it shows us how much would it cost us if we delay the repair by a minute. However, we can also think of it as a speed to value. In this interpretation, if it took a minute to achieve, we’d get a $50 value saving from the whisky barrel and just $10 from the beer one.

Thinking of it as a speed to value has another benefit. In physics, when we divide speed by time we get acceleration. Therefore, when we divide the speed to value by the duration estimate, we end up with acceleration to value. In our example, $10/minute divided by 1 minute gives us a value of 10, whereas the whisky $50/minute divided by 10 gives us a value of 5. The higher value for the acceleration to value is a simple and reliable indicator that that initiative should be undertaken first. In my experience, thinking of acceleration to value is a lot easier to wrap your mind around than "Cost of Delay Divided by Duration" (or CD3 as it's sometimes referred to).

In this manner, you can develop a cunning practice of ordering your Product Backlog in such a way as to maximise the acceleration to value. Items with the highest acceleration to value would be worked on first.

The Scientific Method to the rescue!

This economic assessment is equivalent to using the scientific method: making a theory, running some experiments, assessing the results, then improving the theory. First, we make a theory of which items are most important to work on – the value model, speed to value and acceleration to value concepts are elements of this theory. Then, we run some experiments by creating items in the order suggested by the theory, and assess the outcomes. Based on the findings, we can then decide to continue to use our theory as-is, or adjust its elements to improve its predictive ability.

It’s conceivable that in some cases dependencies across items may sometimes drag items with smaller accelerations to value closer to the top of the backlog. However it would only happen if it enables the creation of an item with acceleration higher than everything else.

The Quality of Order - What's "good enough"?

The quality of the order of the items in the backlog is driven by the accuracy of the value model used to determine speed to value. The result is further influenced by the accuracy of the effort estimates. Overall, it’s good to remember you don’t need a “perfect” model. You just need something “good enough” to give you a promising order to experiment with. Having a system to create and assess value is far more effective than just random decisions.

The overall intention is to figure out how soon it’s a good idea to stop. Your development team will have a known burn rate.  You’ll want to stop work on this product as soon as the value of the items you’re trying to build is lower than the cost of production over the same duration.

So, what's the role of the Agile Project Manager then?

I find that invariably, after I give a brief introduction to the Agile mindset, someone will ask "So, what's the role of the Project Manager in an Agile work process then?"

Let's take the Scrum framework as an example of a typical Agile way of work. Since it only includes the Product Owner, Team Member and ScrumMaster roles, some people may wonder what is to become of Project Managers? Surely, there must be a role for Project Managers in the Agile work process, right?

The short answer is that there are multiple roles available for the Project Manager - each person will have to choose according to their personal experience and aspirations.

All effective Agile work processes take advantage of sound project management practices. The various PMBOK knowledge areas still need care and attention - using an Agile work process doesn't involve any magic that would effortlessly resolve issues of managing integration, scope, time, cost, quality, people, communications, risk, procurement or stakeholders (the fifth version of the PMBOK guide now includes a new chapter on Stakeholder Management).

Agile teams address these issues in a manner culturally different to traditional project management approaches. Rather than concentrating the responsibility to manage the concerns of all project management knowledge areas into a single person (the Project Manager), effective Agile teams rely on all members of the team to contribute their efforts and expertise. Experience teaches us that synergy drawn from diversity is consistently far more effective than individual effort, no matter how heroic a single person might be.

Project Management or Product Management?

A vital distinction is that Agile work processes tend to be focused on perfecting the art of product management, by creating, adjusting and sustaining a product over time in response to feedback from its user community - a product may have an indefinite lifespan, and ever-evolving scope, limited only by its market relevance. On the other hand, by definition:

A project is a temporary endeavor undertaken to create a unique product, service or result.

This dynamic leads to a number of significant implications for the practice of project management in an Agile product development context. The project management disciplines are still vital, regardless of the nature of the work process one might use.

However, there is no room for a traditional Project Manager in an Agile work process, as long as the person insists on behaving with exactly the same habits. For example, in an Agile work process, we cannot continue to expect to have a single person assign tasks to people. Instead, team members self-organize to identify and agree which tasks they should best perform and hold each other accountable for achieving them to meet the Team's commitments.

Does this mean there is no need for Project Managers in Agile work? Not at all - on the contrary, there is a desperate need for Agile Project Managers. If people with a project management background are willing to transform the way they work, they are best placed to make a decisive contribution to changing the world of work for the better for everyone.

The Project Manager as Product Owner

Some Project Managers may have sufficient depth of knowledge in a particular industry or market such that they would make outstanding Product Owners (or Proxy Product Owners).

The Project Manager as Product Manager

For large or complex products that may involve quite a few aspects besides software-intensive systems development, a Project Manager may consider the role of Product Manager.

Using a Product Manager/Product Owner pair for such products, the Product Manager may focus more attention on the customer-facing and non-software aspects, while the Product Owner may devote their attention with priority to the software-intensive systems development activities. For best results, these two people must keep their thinking synchronized at all times. Otherwise, waste and disruption follows.

The Project Manager as Program Manager

For product development efforts that involve many teams, Project Managers may consider playing the role of Program Manager, working with the various teams to coordinate their deliveries. Most of the program management disciplines can continue to be applied in a rather straightforward manner to Agile product development programs, provided the Program Manager develops a good understanding of the nature of the Agile work process used by the teams, paying close attention to the way in which scope evolves over time in the pursuit of value for the customer.

The Project Manager as Scrum Master

As more organizations embrace Agile work processes in their quest to delight customers and make work joyful at the same time, we have a dire need for Scrum Masters to act as Chief Obstacle Removers, defending the health of the Team and its work process from impediments and predators in the form of people making unreasonable or absurd demands. Therefore, we hope that many Project Managers will embrace the Scrum Master role in its full spirit, while steadfastly resisting any lingering command-and-control temptations.

The Project Manager as Team Member

One of the factors which is significantly putting at risk the long term health of software-intensive systems development organizations is the way in which they nurture their technical communities. If the only way to achieve career advancement is to let go of hands-on creation of valuable systems components and turn to a management path of some sort, then the organization will consistently bleed most of their hard-won experts away.

There is a significant challenge in the task of invigorating the approach to nurturing a Technical Career Path such that it becomes much more attractive as a long-term investment and many more people would be able to achieve a satisfying career progression without having to leave it.

If work as a Team Member becomes sufficiently valued and respected socially, then it is conceivable that some Project Managers may choose to join teams back again. They might try their hand at testing, designing the user experience, coding, writing - whatever needs doing in an Agile team. Project Managers as team members would most likely prove excellent mentors, helping all other team members to develop a deeper appreciation of the various aspects of effective project management and increasing the overall effectiveness of the team. If their background was technical to begin with, Project Managers may simply delight in coming back up to speed and then refining their technical expertise in one or more domains, taking a more direct involvement in creating amazing systems.

The Project Manager as Agile Coach

Some Project Managers may have the desire and talent to serve as great Agile Coaches. For more on Agile Coaching, consider the Agile Coaching Institute.

The Project Manager as Strategist or Entrepreneur

Many Project Managers have a wealth of contacts within one or more industries. Some may be able to help organizations to identify and pursue promising product development efforts, shape joint ventures where appropriate, and may help to draw together key teams and experts that can bring them to life.

When preparing programs to start producing new system increments, seasoned Project Managers are well placed to identify and attract the most promising talent.

The Project Manager as Evangelist

In time, some Project Managers may even become Agile evangelists, bringing the good news of continuous improvement to various organizations, helping them to transform their work processes using Lean and Agile thinking.

Your Voice

The usefulness of such ideas multiplies considerably when people add their perspectives. Please consider contributing your thoughts to this topic in the comments. I would warmly welcome a robust dialogue - all views are welcome, from intense support to abject disdain and everything in between.