Talking with a software development lead recently, I heard, “Probably 50% of our user stories have some sort of issue that shows up in UAT or when the QA team finally tests them. It’s not usually major bugs, but we’re doing some amount of rework about half the time.”
What struck me most wasn’t that data point but the lack of emotion around it. There was a sense that the BAs probably could give better requirements some of the time but, mostly, rework is just part of life.
It doesn’t have to be.
Work should mostly flow in one direction through a team: idea → production.
When work goes backwards, that’s a sign something’s wrong. Not with the work item, but with the system.
Here are three system improvements that we’ve seen reduce or even eliminate rework for our clients…
1. Complexity first — fixes rework due to incorrect assumptions
One big source of rework is incorrect assumptions at the outset of a project. For example, during UAT, it becomes clear that the actual business process is different from what everyone initially thought. Sometimes, a whole set of decisions are downstream from that assumption, meaning lots of rework.
The fix? Tackle complexity first. Brainstorm and prioritize assumptions. Test the low-evidence, high-importance assumptions first.
This doesn’t eliminate the surprises—your assumptions still won’t always be right. But you’ll falsify the incorrect assumptions when it’s cheapest and easiest to pivot.
Our CAPED approach is a systematic way to do this at the initiative level.
2. Collaborative specification — fixes rework due to misalignment/ misunderstanding
Another source of rework is information lost at handoffs. The business analyst understood the business rules. The developer thought they understood what the BA communicated. Eventually, it became clear that there was misalignment when someone else tested what was built.
Instead of finger pointing about who missed it, try collaborative specification a la Specification by Example or Behavior-Driven Development.
For a new capability in your system, get product, development, and test perspectives in a working session and brainstorm examples of how the capability works. Product people are great at sharing examples of the happy path, how things work most of the time. Developers are great at proposing “…what about this…?” variations. Testers are skilled at finding the edge and failure cases. (BDD people often refer to this trio of perspectives as “the three amigos.”)
Working with concrete examples builds alignment better than abstract specifications. And examples easily become test cases that can be automated to ensure you build the right thing and don’t break it later.
Check out my BDD book for an emphasis on the collaborative part of BDD.
3. Build quality in — fixes rework due to buggy code, including regression bugs
Some rework is due to intending to build the right thing but somehow missing it (or breaking something else in the process). This isn’t a specification problem. It’s an implementation problem.
The fix here is beefing up your engineering practices to build quality into your system.
Behavior-Driven Development ensures you’re implementing the customer-facing behaviors you intend and not introducing regression bugs later. Test-Driven Development ensures code does what developers wanted and makes it easier to pinpoint the source of bugs. Continuous Integration catches issues when they’re fresh and easier to fix.
And as a bonus, a system with a strong safety net of automated tests becomes easier to change, so teams that adopt these engineering practices often get faster even as they increase quality.
Reach out to explore whether your team is ready to level up your engineering practices.
The bottom line
Rework doesn’t have to be part of your life. It’s possible to set up a system where you resolve complexity early, avoid misalignment, and build quality in.
Is 2026 the year where your team finally says goodbye to rework?
Last updated