Feb 262016
 

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, and so on.

For teams that have not yet become a true Agile team (every sprint is developed, tested, and production ready), one pattern continues to show itself even though this pattern is a carry over from the days of large waterfall projects. This 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: analysis and design, develop, test. This was the rule of thumb used to generate a high-level estimate (HLE).

This rule of thumb was great when it was applied evenly to all three categories. However, what usually happened on software projects is that the first two categories needed more time and 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 two first categories doing the work, there would be no product to ship. However, for some reason, no matter how many changes occurred in the first two categories, the testing was usually squeezed to fit in the original 30% budget. It didn’t matter how complex the testing was, the team was forced into the 30% budget, which always meant that testing had to be reduced. 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 rework 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 three, six, or 12 months without any intermediate deliverable. 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.

In a recent Cutter Agile Product Management & Software Engineering Excellence Advisor, I continue this discussion of Agile, Lean, and building in quality.

avatar

Maurizio Mancini

Maurizio Mancini is a Senior Consultant with Cutter's Agile Project Management and Software Engineering Excellence practice. He is a leader in the QA and process industries with a sixth sense for QA, Agile, and business process

Discussion

  One Response to “Don’t Assume a 30% Allocation for Testing on Software Budgets”

  1. Completely agree with you Maurizio – testing sometimes can be the most undervalued element with software budgets. However it’s often the most crucial element – functionality can be further developed, design can be adjusted or tweaked. But if the product runs into a bug it could have the potential to significantly upset the customers that you’ve worked so hard to please in the design and build.

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)