Agile budgeting II of II - Strategy level and Cost accounting

<< Part I

Strategy level

Plan at multiple levels

Strategy: Having a strategy is more than just having a set of objectives collecting dust, possibly at some cloud unaccessible space, that no one minds looking twice. Strategic initiatives Are important to filter aligned from unaligned ideas. You should use them regularly to keep your aim towards the objective. The project you had planned might attack what you think will happen but not address exactly what you want to happen.
If new ideas or initiatives come to you, in a product leadership position, and your vision and end goal is clear you might want to compare that objective with the new initiative and take that if it has a more likely to be right.

Budget

• Target
• What we want to happen
• Strategic themes / Initiatives
• Forecast
• What we "think will happen" IS different than "want to happen".
• BE CAREFUL HERE
• Resource Allocation
• People and resources we need to make it happen
• Operating budget
• Allocation of budget to streams.

Resource allocation

Allocate funding at the value stream or product level. Don't let location/site organization define how you do the project. Define a collection of teams that work together to get the baton to the finish line.
Allow for dynamic reallocation of budgets across value streams / products. Telling people what you're going to do with the money so far from now makes no sense, don't give that sense of security over something you don't have clear.

An approach - rolling budgeting

• 100% of available funding allocated for Q1
• 80% of available funding allocated for Q2
• 60% of available funding allocated for Q3
• 40% of available funding allocated for Q4

At the end of Q1 you can raise the budget allocation in the remaining 20%

• 100% of available funding allocated for Q2
• 80% of available funding allocated for Q3
• 60% of available funding allocated for Q4
• 40% of available funding allocated for Q1-Y2

Strategic planning with a Kanban board

If you are familiar, with the kanban board, here's an idea for handling strategic planning,
Separate it in the following columns:

• Upstream
• Pool of Ideas (All) 
• Strategic filtering (24-48)
• Ready for inception (24-48)
• Product planning (12-24)
• Ready to Schedule (4-12)
• Portfolio Planning (4) 
• Within teams
• Portfolio Backlog (20)
• In process (4)

Let me first separate and focus on the Upstream: this is where you will have to do the previous work with the leadership to define, based on what are the strategies you are aiming, what are the things that will end up being part of the portfolio backlog.

You will most likely will want to accept all the ideas as they come to be reviewed, I wouldn't place a limit there, although you can prioritize always as you see fit.

You can now with your leadership team filter the ideas in regards to if they are aligned to the strategy or not. Here we start putting a Limit to the WIP (as in Work in Progress), the limit is key although the actual final numbers are just an idea you can define what amount makes sense for you.
Once the strategy filter was passed you can (as long as you have space in the ready for inception column) move that there. No more push to the next column, now it's a pull system to take new stuff.
Product planning should be considerably smaller in comparison to the inception ready list (like half of that list), and ready to schedule even smaller.

Keep your options smaller to be effective in the ones you chose. To follow this plan, do not move things around if the WIP limit would be compromised, it's key to make this work.

Estimate for precision not accuracy. (Example)

XS  USD 10k to 25k
S  USD 25k to 50k
M  USD 50k to 125k
L  USD 125k to 350k
XL  < USD 350k

This should be easier to define than an exact number. (Prices here are just for the sake of explaining, feel free to fit this within the price bands you consider more aligned to your team structure).

Emergent opportunities

You might want to deal with emergent opportunities quickly. Emergent opportunities arrive continuously and randomly, they are perishable - Their values decay over time (frequently exponentially).

Size affects performance

Product/project size affects overall portfolio performance: What happens if you get behind the large farm vehicle on a single lane country road?
All cars behind it suffer the cost of delay. Is actually causing economic damage. A large item in your portfolio hogs the road, consumes large resources long periods of time, cause a convoy effect in your portfolio, which means smaller items that could have gone quickly can't and they're experiencing a cost of delay. summing up all the cost of delay from the small ones. Try to avoid that.

The importance of a WiP limit

Why should a good restaurateur not seat paying customers at an available table if 30% of the servers/waiters called in sick that evening?.
Because serving all the tables will get you a lot more of serviced tables, but bad service since they know they won't do a good job in servicing all. Do fewer but better.

COST accounting

Misalignment with finance team on classifying development costs.
Finance could tell you "Since we don't know agile, all is expense, no capital there".

That will imply that you'll be Overpaying taxes, understating value of what you are doing.  Accounting standards use waterfall examples to explain capitalization rules. You place capitalization when:

• Achieved technical feasibility
• Written managerial approval to development
• Committed development resources
• Management confident of success
• (In waterfall capitalize on coding and testing).

Agile financial reporting

Now, how do you define expense and capital in Agile?

• Expense for
• Portfolio and product planning, expense
• Defects and knowledge acquisition expense.
• Capitalize for
• Release planning, estimating workshop capitalize
• Features capitalize.

Tracking hours

Thing about this is that:

1. People hate it.
2. Fill it out to achieve a target number.
3. Hours above threshold limit may or may not be accounted for.
4. Gives the illusion of precision.
5. Ignores the fact that the team is the unit of capacity.

Use story points instead of hours

• Addresses cost at a much more meaningful level.
• Many teams already use them.
• Simple, reliable and easily verifiable.

Now finance might have the fear of being audited, and not being able to explain this. But actually this is easy, let me give you a quick example:
Team has a fixed cost per sprint, (you can reach HR and they'll tell you how much that is).

Let's say the team brings 40 points of work and
30 points are new features
5 are defects
5 are knowledge acquisition
=>  25% expense 75% capital.

(Defects that weren't captured on prod, or not worked on deployed features are not expense).

And that's it!

Feel free to ask me for any doubts you may have,
or if you aren't sure this would (or not) be the path for you and your organization.