Don’t Assume a 30% Allocation for Testing on Software Budgets

December 2, 2016 — Posted by Maurizio Mancini

The software engineering field has changed a lot over the years. There have been many advances in the field in terms of tools used, how teams build and test software, the speed of delivery, etc…


For teams that have not yet become a true agile team (every sprint is developed, tested and production ready), there is one pattern that continues to show itself, even though this pattern is a carry over from the days of large waterfall projects.


The pattern is, the projection and allocation of budget based on the one third rule. In the days of large waterfall projects, organizations made the assumption that a software budget was allocated one third per major category of work: analysis and design, develop, test. Analysis and design includes the architecture work for the project. This was the rule of thumb that was used to generate a High Level Estimate (HLE).


This rule of thumb worked well when it was applied evenly to all three categories to generate a HLE. However, once the work actually started, what usually happened was that as the first two categories of work needed more time than estimated, it inevitably came at the expense of testing in an effort to stay on budget.


This pattern has caused grief to many testing teams over the years. For some reason the design and analysis or the developers always got more time when they asked for it. The thinking was that without these 2 first categories doing their work, there would be no product to ship. However, for some reason no matter how many changes occurred in the first 2 categories, the testing was usually squeezed to fit in the original rule of thumb. It didn’t matter how complex the testing was or became, the team was kept at a max of 30% of the budget and usually it got reduced as the other teams continued to chew up the budget dollars. This almost always meant that testing had to be reduced to levels well below 30%. Reducing testing inevitably lead to that vicious cycle of problems in production, which eventually would come back and cost the organization money by having to allocate more and more of future budgets to technical debt in the form of re-work and corrections, rather than new features.


Move the clock forward to today and unfortunately for teams that haven’t become true agile teams, the pattern continues. Organizations think they are Agile but for some reason they are still planning releases to production that are only every 3, 6 or 12 months without any regular deliverables to production. Testing is still thought of as a separate entity within the sprint and the team is usually unbalanced on the number of quality resources. You will usually find a “hardening sprint” or “stabilization phase” at the end of the sprints but in most cases the question of not going beyond the 30% of the budget for testing is still very top of mind in these organizations.


If an organization is going to work in this type of environment, then they should be applying the same rules as they used to in the past, an equal amount of time for each major activity: Analysis and Design, Development and Test. However, if an organization wants to remain competitive and be able to release software in a timely fashion, then they need to become a real Agile team that works to build in quality.


Agile, Lean and Building in Quality

When a team moves to using Agile and Lean methods, then this team is focused on delivering value to the organization. When delivering value is top of mind for a team, then the amount of budget per category of work is less relevant. The team is focused on delivering valuable working features every sprint which have been prioritized by the product owner who has already made the business case for the feature.


It no longer matters how much of the budget goes for each category of work, but rather, how many valuable features can the team deliver for the budget allocated.


This also changes the dynamic of how the teams think of quality. It is no longer just the concern of the testing staff, but rather the team now has ownership of delivering a working feature with high quality. Quality is now everyone’s business, therefore the allocation of a budget by category is no longer really relevant.


This new reality has freed up the team to focus on estimating a feature and the work needed to deliver it. The focus is no longer on how much time it should take each category of work to deliver the feature. Yes the team is estimating hours to deliver when breaking down a story into sub-tasks, but the estimate is now a team effort and no longer a siloed effort in which each silo gets allocated limited budget dollars.


Agile and Lean methods have helped software teams refocus on what is really important, delivering awesome quality software that delivers value to the organization!


If you want to know more about how Agile can help refocus an organization on delivering valuable features and maximizing your budget dollars, please​ ​contact Exempio or Net Objectives​ for a consultation.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Maurizio Mancini

Maurizio Mancini is a leader in the quality and process industries with a sixth sense for Agile, quality, and business process. He is best known for cutting through the noise and getting to the heart of any organizational problem whether that problem consists of choosing the right software development process, implementing modern quality approaches, or just finding the right balance between people, process and tools. Maurizio’s approach consists of empowering people and teams so that the team's talent and creativity comes through naturally. This mindset favors the adoption of Agile values in any environment.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban