Never Enough Time to Test

Never Enough Time to Test

not-enough-time-to-testI’ve worked with dozens of organizations and teams making the transition to Agile – specifically Scrum. The same issues constantly arise, almost always around testing. According to Scrum, a Product Backlog Item (PBI) is never done until it is potentially shippable. That means code complete, tested, and documented, with a pretty bow on top…it’s not just done, it’s done done.

Because we work in a timebox – the Sprint – we have a hard date from which to work backwards, usually two weeks. So this begs the question, while developers are coding away in the beginning of a sprint, what the heck are the testers doing? Sure, they can develop their test plans, but that isn’t as time consuming as development, so I usually see testers relatively idle until developers start closing out tasks.

This workflow creates a dilemma, where the sprint is inevitably end-loaded with testing work, leaving little time for rework and bug fixes. Often times, PBIs are incomplete at the end of a sprint, and they spill over into the next sprint for completion.

One could suggest coding in one sprint, and then testing in the next, but this is effectively accelerated Waterfall, sometimes called Scrummerfall or Waterscrum. Whatever you call it, it’s anti-Agile.

Another remedy could be to extend the sprint from, say 2 weeks to 3. But that generally has the effect of Parkinson’s Law on the sprint, where the work expands to fill the time allowed. You still end up with an end-loaded sprint; you just take longer to end up in the same place.

How do we get testers testing sooner, and prevent developers from rushing to get incomplete work in their hands?

When refining the product backlog, we look for opportunities to decompose items. This helps create more fine-grained tasks, which in turn can be coded and tested with greater throughput. As these PBIs are selected for inclusion in a Sprint, we can enjoy a more fluid workflow.

Challenge Questions for Business Leaders:

  1. How effective is your team at maximizing their throughput and efficiency?
  2. How well does your team work under pressure to deliver on tight deadlines?
  3. How much happier would your customers be if given smaller feature enhancements, but much more often?

© 2015 Mark Richman. All Rights Reserved.


AWS migration and transformation programs reduce cost, risk, and complexity for rapid business innovation and agility at scale. I offer a number of AWS consulting services, including an AWS migration service to quickly get you up and running. Please contact me for details on how I can help your organization.