In-Sprint Automation Through the HIST Lens: Discipline Before Speed

In the past 10 years everyone talks about in-sprint automation like it’s the ultimate Agile goal. It sounds perfect because we build the feature, automate the tests, and ship all within the same sprint. Sounds reasonable or too good to be true?  But anyone who’s tried it knows it’s not that simple. So here’s my question: When is in-sprint automation actually doable and when is it just a dream which will never come true?

Let me first explain what do we mean by "In-Sprint Automation" for our junior testers audience. It means writing and running automated tests within the same sprint the feature is developed, so automation is delivered with the feature, not pushed off for later. Sounds great in theory. But to pull this off consistently, a lot of things need to go right.

So let me share my experience based on 79 automation engagements when In-Sprint Automation can actually work.

1. User Stories Are Clear and Don’t Constantly Change

If your stories are half-baked or getting reworked mid-sprint, forget it. You can’t automate what isn’t settled. And do not forget we are in agile and the big excuse here is: “Well user stories can change till the last day of sprint”. Really? Not in my quality world. We should have discipline in place and finalize user stories as early as possible without any future changes.  Yes, this is where HIST (Human Intelligence Software Testing) discipline comes in. Well-defined acceptance criteria and early test reviews (HISTers love this).

2. Test Design Happens Before or Early in the Sprint

Automation doesn’t start with code, it starts with thinking. Good test cases should already be drafted when development begins. For those who ask, "Why draft test cases if we haven’t seen the feature yet?" you can simply say, "Because HIST instructs and demands this."

More importantly, we must begin designing test scenarios and test cases during backlog grooming or sprint planning. No, they won’t be final at that stage and they don’t need to be. The goal is to start thinking critically early, identify test conditions, and be ready to refine as the sprint progresses. Delaying test design until development is complete is exactly what leads to poor coverage, rushed testing, and missed defects.

3. Automation Engineers Are Involved from Day 1

They can’t just jump in at the end of the sprint and magically automate everything. Collaboration has to start early, this is the critical hint. You need at least one dedicated Automation Engineer, though ideally two. And they shouldn’t be pulled into functional, compatibility, usability, or integration testing tasks. Their focus should remain on building new automation scripts and maintaining existing ones, keeping them in a consistently executable, reliable state. Diluting their role with unrelated testing responsibilities only delays progress and undermines the value of in-sprint automation.

4. You’ve Got a Reliable CI/CD Pipeline

If your builds are slow, flaky, or still rely on manual or semi-manual steps, automation won’t help, it’ll only slow things down further. Your CI/CD pipeline should function like a well-oiled factory, capable of supporting multiple reliable deployments per day.

5. You Have a Reusable Framework That’s Ready to Go

Without a flexible, well-maintained framework, writing new scripts each sprint becomes a nightmare. Build once, use many times. I will share new article in the next few days on what ideal automation should look like in my opinion.

6. You’re Not Drowning in Technical Debt

If your environments are unstable, test data is a mess, or previous scripts constantly fail, don’t expect magic now. Clean up your mess first, automate second.

7. You Prioritize the Right Tests

You don’t need to automate everything. Focus on what matters most for the sprint, critical functionality and high-risk paths. Use human intelligence before, during and after automation. Apply HIST perspective which states: "Risk-based thinking always wins".

8. Your Team Actually Works Together

Dev, QA, Product, and Automation must collaborate daily not just hand things off. Ask yourself: "Is your team cross-functional, or just dysfunctional?"

Now let’s talk about when in-sprint automation falls apart, because trust me, I’ve seen that movie more times than I can count.

Watch out for these signs:

• User stories change mid-sprint
• Testing starts too late
• Automation is rushed in the last 1-2 days
• Environments aren’t ready
• Manual testers are forced to do automation
• You don’t have at least one dedicated full-time automation engineer (FTE) focused solely on automation efforts within a Sprint.
• CI/CD is unstable or missing

In these cases, forcing in-sprint automation can do more harm than good. Better to delay by a sprint and do it right.

The HIST Angle

In Human Intelligence Software Testing (HIST), we don’t chase automation for the sake of speed. We chase value, stability, and smart prioritization. For us, in-sprint automation only works when:

• Manual test case development is initiated early, ideally before the sprint begins and is performed by QA Subject Matter Experts, not Automation Engineers.
• Test data and environments are already prepared
• Automation focuses on what really matters to the business
• Quality is everyone's job but testing is still a discipline and QA owns the quality.
• You have dedicated Automation Engineers embedded within the Scrum team, solely focused on automating new user stories and maintaining existing automation scripts without being distracted by unrelated testing or support tasks.

Final Thoughts

In-sprint automation is possible. But it’s not a checkbox. It’s not "write test fast, check it in, and move on". It’s a collaborative effort that requires planning, trust, readiness, and maturity. If your team has those things, great you should go for it. If not? Don’t fake it. Take the time to build the foundation first. Because the goal isn’t just fast delivery, it’s quality that lasts beyond the sprint.

********************************************************************************************

Catch up on HIST (Human Intelligence Software Testing) if you missed my earlier posts and follow me for honest, unbiased, no-nonsense insights about QA and the future of our craft.

Recommended Reading: Explore more about Human Intelligence Software Testing (HIST) discipline and how it's reshaping modern QA.

Why I created Human Intelligence Software Testing (HIST) and Why It Matters Now More Than Ever?

I Watched 76 QA Positions Disappear and It Made Me Question Everything

The Quiet Crisis in QA: Are We Forgetting the Human Factor?

The Slow Death of QA - A Problem We Helped Create

When Tools Stop Thinking, HIST Begins

7 Days of HIST: Support, Skepticism, and Why This Conversation Matters

How 2 Months of Training and a Fake Resume Landed a QA Job: The Harsh Truth of an Industry Loophole

HIST vs. RST: It’s Not a Competition—Each Has Its Own Purpose

HIST vs. Exploratory Testing – Two Different Worlds

Don't Let ChatGPT Be Your Voice: Reclaiming Human Intelligence in QA

How Agile May Have Damaged the QA Discipline: A Wake-Up Call

Why One of Your Greatest Weapons as a Tester Will Always Be Human Intelligence

The Death of QA Leadership in Agile and How HIST Brings It Back

How HIST Fits Within Agile and Heals Broken Processes

Exploratory Testing vs. Investigative Testing: Is It Time to Evolve?

Beyond Shift-Left: Enter the Era of Human Intelligence Software Testing

27 Years Later: Why QA Still Fights the Same Battles

The Unspoken Truths Behind Agile: Why Testers Are Afraid to Speak