You’ve heard about the cost of a bug—The longer it takes for a bug to be discovered, the more expensive it is to fix. But have you ever considered the cost of a reject? Do you have visibility into how much rejected stories and bugs are affecting your Scrum team’s capacity in terms of time?
Let’s take a look at just how impactful rejects can be, and how to mitigate them when they occur.
The Cost
Start with an average story or bug ticket in a hypothetical Scrum team:
A story or bug ticket is created and assigned to the sprint.
The bug has steps to reproduce—if the writer was efficient.
For the story, QA and the Scrum team determine the test strategy.
The developer works on the ticket and pushes it to QA.
QA verifies or rejects the ticket.
Different tickets take different levels of effort. For the sake of this article, let’s assume it takes an average of 30 mins for QA to verify the ticket.
At least, that’s what happens when all goes well.
If QA experiences unexpected results, then the following becomes necessary:
Revisiting the steps to see if a mistake was made.
Checking the requirements.
Double-checking everything.
This has just added another 30 minutes to a ticket. Now the ticket is rejected, and returned to the offending developer.
The developer now has a new clock that has started on the ticket. Considering the back- -and-forth with QA and the designer/product/business owner, plus the fix and deployment, you can expect to take about one and a half hours to do this additional work.
Once all that is over, things are back in QA’s hands. QA has either modified their tests, or they are working from the original set. Quite likely they are now suspicious of the code, and will do their due diligence to make sure the surrounding areas to the fix were not impacted. We’ll give this an average effort of one hour.
At this point the rejected ticket has cost the team an overall three hours of capacity!
In the scenario above, we’ve discussed just one reject. Imagine how many total hours of productivity are lost to rejects per week, per month or per year across the organization as a whole.
Are You Aware of Your Rejects?
Most teams I’ve seen have an informal process for identifying issues during a sprint. Usually the agreement is to keep the process light, in the spirit of Agile. If a Scrum story is rejected, then it is moved back in the sprint’s swim lane to be “In Development.” This could happen repeatedly until it finally gets through QA.
In the case of bugs, there is usually a more formal process of using the ticket’s status to actually reject the ticket and return it. However, even this can be seen as unnecessary overhead, and while the ticket status remains “In QA,” there is a behind-the-scenes collaboration occurring to get the bug fixed and redeployed.
Since Scrum teams are self-organizing, whatever works for the team is fine. But somewhere, someone should be tracking these reject events. Otherwise, you do not have visibility as to where things are breaking down and how to fix them.
A simple tactic that has worked for my teams is to have the QA engineer keep a running tab. When the team has their Sprint Closeout and Retrospective, they can include this type of information as part of a standard sprint report. Over time the team can use this simple metric to identify if they are experiencing a flux in their capacity due to rejects.
How Can Your Team Prevent Rejects?
There are a couple of ways to immediately prevent and address rejects when they start becoming a problem:
The Three Amigos - Most of the rejects are caused by an inconsistent understanding of the requirements between the originator, the developer, and QA. This means that better communication is needed between them. Introduce the concept of The Three Amigos to facilitate collaboration and identify the holes in the process.
Test Early and Often! - Using Test and Behavior-Driven Development (TDD/BDD) techniques will force early recognition of a misunderstanding of specifications. The earlier in the process you apply your automation, the sooner an issue is ironed out. Automating your deployment processes removes those random environmental issues that are often the cause of a reject.
Teams should always strive for efficiency. Tracking story and bug rejects is another tool to improve a Scrum team’s ability to handle more story points.
Joe Nolan (@JoeSolobx) is a QA Team Manager with over 12 years of experience leading multi-nationally located mobile and web QA teams, and is the co-organizer of the DC Agile Software Testing Group (DCAST) Meetup.
