Skip to main content


One of the biggest surprises in an agile environment is that you can have completed code at the end of your two-week sprint and still not cross the finish line. What’s the problem? Testing. You know you’re supposed to test at the end of each sprint, but with goals to meet, it’s tempting to rush past QA. The problem is you’re not reaching your goals if you’re not testing, and bypassing QA comes with extra costs. Here’s what you need to know.

Developers have a short memory.

In order to finish your sprints on time, you may find yourself putting off testing until later. “Later” becomes a month or two, and suddenly QA is reporting issues, but your developers can’t remember what they wrote all those weeks ago. They also didn’t do the necessary documentation, so fixing the bugs slows down the project and costs additional labor. As one person said, “We say we’re doing agile but what we’re really doing is waterfall without documentation.”

QA will never be less understaffed than they are now.

You’ve got fifteen developers and, while you should have seven or eight QA people, you only have two. You keep putting off testing until QA has more bandwidth, but that day never arrives. Now it’s the end of the project, QA is more overloaded than ever before, and it’s time to release. You do the minimal amount of testing and cross your fingers that everything else works as it should.

Rework costs more than you anticipate.

Now that you’ve rushed through testing, your software is on the market and bugs are being reported on a daily basis. You’re looking at months of rework, costing you unexpected time, labor and money. You aren’t alone: The NIST (National Institute of Standards and Technology) has estimated that software defects cost the U.S. economy nearly $60 billion a year*. And of course, correcting a bug after release costs exponentially more** than fixing it during QA, which is still more expensive than catching the bug during coding.

In agile, testing isn’t a “nice to have” to be done after the goal is met; it’s an essential part of meeting the goal. To be successful you have to change what you’re working towards.

Aim for completed functionality, not completed code.

In true agile, the only way to achieve your goal is with completed functionality—i.e., potentially releasable code that does what the business owner requested. Completed code doesn’t require testing, but completed functionality does. By making testing part of the criteria for reaching your goal, you ensure that your progress in each sprint is real.

Don’t be afraid to move the finish line.

If you can’t reach completed functionality during the typical two-week sprint (whether because of a lack of resources or a particularly challenging project), reset your expectations and find the level at which agile can be successful. Extend sprints to four weeks or reduce your goal from 20 to 10 points per sprint. But be consistent and remember: Only completed functionality earns points, not completed code.

Committing to the agile process and working towards functionality requires discipline, but in the long run you’ll find your efforts rewarded—with lower costs, greater efficiency and a much stronger end product.


  • Computerworld
  • Codeguru

For more QA best practices, download our free ebook: Breaking Agile’s QA Bottlenecks

Randall McCroskey

About the author

Randall McCroskey

Vice President, Enterprise Solutions

Since 2006, Randall has been helping technology executives digitally transform their business as Vice President of Pyramid Consulting. Relationships are his daily driving force and his desire to trust and serve those in his professional and personal life constantly motivate him. Atlanta is a great city for Randall, as he hates the cold and prefers warm weather near the water. His greatest pride is the partnerships with colleagues, friends, and fellow professionals he has made along the way.

Cookie Notice

This site uses cookies to provide you with a more responsive and personalized service. By using this site you agree to our privacy policy & the use of cookies. Please read our privacy policy for more information on the cookies we use and how to delete or block them. More info

Back to top