Like it or not, it's always about time and money...

My wife and I love to travel. Every year, we spend time contemplating where we would like to go next. Sometimes we spend a bit of time day-dreaming of what the place might look like and what airlines fly there etc...Then...back to reality.

We keep these places in a list (usually our head) but they aren't very detailed. We do know that October is the likely date we will spend a vacation by ourselves and then usually a family trip in the Summer / Spring break if we can. Why can't we go on vacation every day, every week, or every month? You guessed it, we are bound by time and money. First, we couldn't afford to go on those trips every month because we have a household to run that contains 2 adults and 4 children. We have expenses with cars, house, insurance, food, etc...

Let's say we did have all of the money in the world. Our next problem is we are bound by time. I *get* to work in order to provide for this wonderful family. My wife owns her own business and dedicates a ton of time to those affairs. That alone takes a significant portion of our availability. The reality is, no matter how much we love/want to travel, we can't do it at the frequency we would hope for until we retire. Even then we are bound by time and money.

I work with many wonderful product development teams; mostly in the software space. It floors me how stakeholders burn through a team's capacity like their is no boundary on their time. Building a backlog of work in agile is similar to the problem my wife and I face. How do we prioritize the trips, how much time to we spend planning for the trips, and what factors govern the scope of the trip. If we want to go to Fiji, we know that is a long trip and will likely not happen this year. So why would I go book / research airfare tickets, hotels, and plan out my every day if it is not even a priority. We would perhaps do some high level cost analysis to help determine if we even want to prioritize it, but not a detailed plan. Too much can change by the time we actually go on the trip.

How do we prioritize the projects (infinite list of things to do), how much time do we spend planning for the projects (many things change, we risk waste if we spend too much time), and what factors govern the scope of the projects (other projects, capacity, time, business needs, etc...)? If we spend too much time on details for the project that is far off in time, we will never get that time back on the things that changed. In agile people think we don't plan or can't give dates. That is false. We just don't give good dates for things that are a long way off, but things closer to delivery, now that is a different story.

The amount of time we spend on our backlog in agile should be much like driving a car in the dark down a long highway. Things in front of the car are well lit, detailed, and understood. Things 5 miles down the road are seen, but not much is known about them. If your car is really fast, then you have better lighting to see further down the road (you'll get their quicker). If your car is slow, then you don't need the high powered headlights.

As a Product Owner, you are pretty much like the CFO of your team's capacity (another blog on that later). As your stakeholders ask for more projects to be done, you don't necessarily decide which one is the best one; alone. You gather all of the stakeholders and align them on the priorities of the work with respect to the limited capacity and time. Business needs also play an important part.

Look at any organization that has a CFO. We could not simply walk in and say "I need this amount of money" without providing details on why you need the money. In fact, the CFO would likely not be the deciding factor, they simply facilitate the other stakeholders (Executives) around the fact that we don't have unlimited funding so we have to work together as disparate departments to allocate the funds. Some departments get what they want, others don't.

Remember a core tenant of agile is that we want our people doing the work to operate in a constant, sustainable pace. While money is an inanimate object, people are not. Respect their work/life balance and provide the ultimate protection for them by managing your stakeholder's expectations much like a CFO would manage the scarce supply of money for an organization. You are the steward of the team's precious capacity. Let's get consistent at measuring what that capacity is each quarter and cap scheduled work at an agreed upon capacity limit. In fact, your stakeholders can't have 100% of the team's capacity, you will have to budget for other things that aren't project specific.

We have many techniques to help you do this, join us for one of our Certified Scrum Product Owner workshops available to the public or we are happy to assist with a customized prioritization workshop for your stakeholder teams. We should strive for a repetitive process of prioritization so that when capacity is not enough to meet business needs, we explore ways to increase capacity (without necessarily always working overtime). If your business does not have enough money, your CFO's job is to explore options and risks.

Like it or not, it's always about time and money.


Related Articles

Embracing Emergent Work

As I practice Scrum and tackle issues in Scrum Teams/Organizations, one common theme "emerges". Emergent is one of those funny words that gets thrown around quite a bit in the "agile" world. The Scrum Guide talks about embracing the idea that work "emerges" during the Sprint. The Agile Manifesto talks...

Read More

How a Product Owner is Like a Business Owner

If you’ve ever wanted to own a business or think like a Chief Financial Officer (CFO), being a product owner has many similarities. A good product owner has to think carefully about how to spend money and what kind of return on investment she’ll get. In most companies, we forget...

Read More

Requirements in Scrum

Let's be honest. Most teams struggle with how to get requirements into their new "agile" process. Take Scrum for instance. Scrum says you start with what is called a Product Backlog. Let's see what the Scrum Guide says about the Product Backlog: The Product Backlog is an ordered list of...

Read More