One of the major push backs I have found from top management levels in different companies when adopting Agile is the fear of not knowing how much are they going to spend.
They usually ask for two things: How much is this going to cost and when is it going to be delivered.
Even though I cannot answer them with the level of confidence they wish for, I can increase such confidence addressing the underlying concerns, by facilitating a self-learning process which provides higher transparency in regards to budget being spent and its outcomes, enabling key decisions around where to invest.
We are all familiar with the concepts of Roadmap, Backlog and PBIs, and you probably use Themes, Epics and User Stories to organize work around them. Regardless of the Agile Framework you are using, I propose to use these concepts with the following structure:
Themes: Link Themes with high level areas of investment, like “Analytics”, “IM Tool”, “ERP integration”, etc. which are highly related to the company’s goals – whether they are current business to exploit or opportunities to explore. Themes can play across projects.
Epics: Use Epics for business requests related to a specific product or project. Be explicit about the business value (why are we doing this?) and the expected outcome or, as I like to call it, the measure of success. HDD (Hypothesis Driven Development) is a good model to follow for Epic composition.
Stories: Let the Story cards be the smallest piece of work you can vertically slice to add value towards a specific business request (Epic).
Now that we have the structure in place, let’s take a look at how we are going to size and measure it.
Themes: Assign a budget to each Theme. This is a common practice in most companies anyway, so it’s BAU. Top management tends to decide in advance how much money they are willing to invest in things like a new configuration tool, analytics, and so forth. It’s advisable to perform scheduled budget reviews to reinvest, halt investment or gain advice from the financial stakeholders.
Epics: Keep it simple and offer them a relative size with a T-shirt sizing technique. Small, Medium, Large and X-Large are typically more than enough.Keep in mind that the size of an Epic could be another valuable input for prioritisation, since typically smaller Epics can be presumed to be less risky to the overall initiative.
Stories: I propose the good old fashioned Story Points mechanism to follow the relative sizing approach, but feel free to use Story count or throughput if that suits you better – Anything that gives you a sense of the team’s velocity will work.
Finally, make sure you have every Story associated with an Epic, and every Epic linked to a Theme.
While you track your velocity, you can establish a direct correlation based on historical data between Epic Size and the number of Story Points it actually took to complete them. So you’ll end up with something like this:
Note: The longer you keep the same team, more historical data is gathered and the correlation becomes more accurate.
Following the same logic, you can start connecting “done” Epics of a particular Theme with the remaining unfinished work. By using the budget already assigned and basic work done percentages, you can get a better idea of the total amount of investment any given Theme will require.
This will also allow you to focus on conversations and discussions at different levels. The top management, for instance, can focus on budget, time to market and ROI using the Themes level while the mid-management and the team discuss topics related to project goals and valuable features for the end-customer through Epics and Stories.
By combining this approach with models like HDD, you can not only get a better sense of the budget spent but also key insights on the impact it is causing. In other words: You will have more control over your return on investment (ROI).
EndNote, thanks and references
Thanks to all of those who in a direct or indirect way has helping me finishing this short article. Their contributions has been really useful.
Thanks also to Javier, who has provided me a wider look about this topic referencing Dean Leffingwell’s book “Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development Series)”. I haven’t read it yet, but for what I could see explain this topic in detail with a much richer context.