How to Overcome the Clash of Annual Budget Planning and Agile Product Development
There will be this moment when you are asked for next year’s product roadmap and budget. Same story every year. You are the product owner in the company, responsible for gathering the requirements and building the digital product. But how do you know what you and your team will work on in the year from now? This short guide will give you a few tips and prepare you for this discussion.
Matthias Siedler is co-founder of carpooling.com, sold to blablacar in 2015 and is a founding partner at Eisbach, a Munich-based consultancy that focuses on supporting companies to set themselves for the right decisions towards digital transformation.
Before you start banging your head, you go through your product backlog. It is in good shape and as a good product owner, you probably have the upcoming sprints already planned. Great. But this addresses a little more than a month of the coming year. What about the other ten months?
OK, there is this other backlog with all the ideas not prioritized yet and you think it might be a good idea to talk to your coworkers in the other departments to grasp their requirements and priorities. No. This is a bad idea. All you will get is unstructured, chaotic feedback. Now, how should you get that in order and how should it be possible to estimate the effort or even budget in the short-term?!
Maybe it is a good time to talk to your boss again: ”Can’t we just allocate the same budget the same way we did last year?” Stupid question — of course not.
“Every buck you spent once is gone.” You got challenged by your boss and he wants to know what features you want to build up the next twelve months — and to make matters worse — he also wants to know their business value.
OK, let’s end the story here. We see discussions like this happening at our clients all the time. The point here is:
Almost every SMEs still does their budget planning annually, also to give their shareholders an estimate of profits and sales for the coming year(s). This demand is then spread across all departments. You must understand that you cannot expect your boss to solve your problem. He/she may claim to understand agility, but even as an IT manager he/she has probably only ever worked in companies with complex and lengthy projects using waterfall project management. Thus, he/she has no real practice of agile methods and customer-focused product development — apart from information obtained from reading books or listening to podcasts on agile practices.
According to the company monday.com, “71% of organizations have adopted agile methodologies, and 90% of agile projects have faster time to market than the average for traditional project management.” (source: https://monday.com/blog/agile-planning/).
So, how can you convince your boss of this (for him/her) new, agile world, but still satisfy him with a roadmap (also for next year)? Here are the five steps you should take: Our recommendation consists of these five suggestions:
- Ask your boss for the overall company goals of the next year
Hopefully, your company already has OKRs implemented. There might also be a mission. But at least there should be sales figures, revenue numbers or similar. This also works. Because it helps to prioritize each initiative you come up to validate its business value in accordance with the company goals. - Next question is “What customer’s pain points do we want to solve to achieve our company’s goals”
To make it clear, a customer from the product point of view can also be an internal customer, a department, etc. With these pain points in mind, you can start to think of possible, high-level solutions and formulate your initiatives. - For each initiative, create business requirement definitions (BRD)
In the “old” world, you typically would fill in pages long project charters. We created a lean version of these project statements, which we call business requirement definition. It is a one-pager consisting of a brief description of the initiative, requirements (like pre-conditions, team setup), rough estimates (typical t-shirt sizes) the most essential part, the business value. This doesn’t necessarily mean a monetary value, but how it contributes to the overall company objectives and goals we ask for in #1. - Now start composing your roadmap with initiatives.
With these BRDs, you can start the discussion with the management. Share the BRDs ahead of your meeting so that everyone can read through the documents. Then have a five minutes discussion and clarify any questions. Lastly have a simple vote on the initiatives and easily define the priorities based on the business value together. Now you are in a position to quickly create your roadmap.
One of the really great advantages of this approach is, that you involve the management in the planning, get a common understanding of the upcoming products and features and get their buy-in. With the help of recent online tools (e. g. there are nice Gantt Addons for Jira), you can visualize the outcome and make the progress available to everyone in the company
Our final advice is: Stop doing that practice annually — do it (at least) quarterly. Market-conditions change rapidly, your product development evolves over time, requirements change. The goal is to keep the roadmap focused on current market conditions and long-term company goals. Having an open, regular communication flow with your boss and the management helps you getting their involvement needed, creating trust, celebrating success, communicating problems early and finally providing world-class products to your customers.
And last but not least: Less stress next year!
