Planning A Yearly Budget For A Long-Term Agile Project

On every large software project — Agile or otherwise — there are management and finance team members who want to understand how much it’s going to cost. There is also a product owner who wants to know the cost of all planned features for the whole year.

For an existing Agile project, there’s usually a predetermined budget that accounts for all of the year’s planned features and projects. And if a project team decides they want more features or projects completed, they can choose to add to the budget.

But what if the project is new and you don’t know the scope of all the features?

How do you know what to budget for? If you expect to deliver a feature in a certain way, what should you do if it requires major development time than you initially thought? How do you figure out some idea of what the overall project will cost?

In working with clients large and small, these are questions and concerns that come up quite often. It’s not always feasible to have long requirements sessions spread over many weeks or take Dev teams away from their work to provide technical architecture. In the absence of those methods, how do you understand the overall effort required to achieve what you want?

Here are some practices I’ve used to provide some level of cost associated with the work you need to get completed.

Make and Prioritize Your Wish List

The very first thing I like to do is have the product team provide a list of all features and projects they would like to complete for the year. This can also be done for shorter periods of time, or when new projects come up as well. The items on the list may not have any real requirements around them yet, but an owner of each item should be able to speak to what is desired. Once this list is compiled, I have the team rank and order each item by priority. A good way to capture this is in a simple spreadsheet but you can also use Jira or any other planning tool.

Discuss Each Item

With that prioritized list in hand, what comes next is very similar to a typical Agile roadmap or backlog grooming exercise but at a very high level. We bring the product owners, solution architects (SAs), and maybe even a technical architect together in a two to four-hour meeting.

As a group, we elect someone to be the driver of the meeting to ensure the team stays on track. For each item in the spreadsheet, the corresponding product owner gives a five-minute overview of the project or feature. The SAs and technical team members will get ten minutes to ask questions, validate assumptions, and call out any concerns. The discussion then stops and moves on to the next item in the list until every item is discussed.

Establish a Cost Range for Each Item

When the meeting is complete, the technical team is responsible for the next deliverable. The goal over the next couple of days is to take each item and create high-level documentation about how it might be architected or built. This documentation should call out any risks and assumptions as well as apply some range of effort it will take for all team members.

Personally, I like to set up a range of hours and apply it to T-shirt sizes. For example:

• Small: 0 – 100 Hours
• Medium: 100 – 300 Hours
• Large: 300 – 800 Hours
• X-Large: 800+ Hours

The ranges can be whatever makes the most sense for your team. As you can see in my example, the number of hours increases with the T-shirt size as the complexity of the project also increases and there are more unknowns. The team then adds to the spreadsheet the low and high hours and calls out the size of the project. The team also lists the assumptions and risks in a column.

Estimate the Total Cost

When complete, the team meets again. This time though, the technical team walks through each item and has ten minutes to outline the approach, what they heard, and walk through assumptions. The product owners then have five minutes to clear up any assumptions or call out if something was heard incorrectly. This is when you can really see if an item has any confusion around it and whether or not you need to park it for later discussion.

Once complete, the product owners can now see potential costs associated with each item. This may change the priority as you will see if something is going to take longer than expected and isn’t worth the cost. Or, identify some low-cost items that will now have a greater impact. Product owners can then look to see which features are above or below the line and prioritize how they fit in the budget.

The Key to Success

The key for this to be successful is that ALL participating parties understand these are in no way binding estimates and costs and estimates will change when the project kicks off. But with all of this documentation completed, your whole team at least has a good idea of what your project will cost, including management and finance team members.

Image Source: Fabian Blank on Unsplash