Skip to content
  • Services
    Our Approach
    Personalized, in-depth technical guidance on a global scale that helps organizations achieve their digital transformation goals.
    Learn more
    • Our Approach
    • Development
    • Design
    • Digital Experience Platform
    • Data & Analytics
    • Cloud & DevOps
    • Support
  • Work
    Our Work
    Through our expertise in strategy, design, and engineering, we help clients deliver digital transformation at scale.
    Learn more
    • Our Work
    • Healthcare
    • Finance
    • Manufacturing
    • Agriculture
    • Education
  • About
    About us
    For over 20 years, we’ve partnered with companies of all sizes and industries to solve their most complex business problems.
    Learn more
    • About us
    • Leadership
    • Locations
    • Events
    • News
  • Careers
    Join our Team
    Take your career to the next level. We offer exciting opportunities across every stage of the software development life cycle.
    Learn more
    • Join our Team
    • Open Positions
    • Application Process
    • Benefits
    • Learning & Development
  • Insights
    Our Insights
    Read our latest blogs, watch our recent videos, and browse our library of e-books — all full of insights from our experts.
    Learn more
    • Our Insights
    • Blog
    • Videos
    • Downloads
  • Contact
Menu

Planning A Yearly Budget For A Long-Term Agile Project

On every large software project, understanding the cost is critical. But what if you don’t know the scope of all the features? We have a proven solution.

Bob Reuss

MentorMate Alumni

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

Tags
  • Agile Software Process
  • Development
Share
  • Share on Facebook
  • Share on LinkedIn
  • Share on Twitter

Agile Software Development

Why businesses need remote Agile teams & questions to ask before starting.
Download
Share
  • Share on Facebook
  • Share on LinkedIn
  • Share on Twitter
Sign up for our monthly newsletter.
Sign up for our monthly newsletter.

Read what's next.

Blog

How to Write Effective Technical Tasks and User Stories

Blog

Measuring the Business Value of Technology Investments

  • Twitter
  • LinkedIn
  • Instagram
  • Facebook
United States
MentorMate1350 Lagoon Ave, Suite 800
Minneapolis
, MN 55408

+1 612 823 4000
Bulgaria
67 Prof. Tsvetan Lazarov Blvd.
Sofia 1592, Bulgaria,
+359 2 862 2632
Sweden
Drottninggatan 29
411 14 Göteborg

+46 3 199 0180
Paraguay
Carlos M. Gimenez 4855
Asunción, Paraguay

+595 21 327 9463

Copyright © 2023 MentorMate, Inc.

  • Cookies
  • Privacy
  • Terms
  • Continuity Policy
This site is registered on wpml.org as a development site.