Running a Two-Week Dev Cycle with ATDD

There's something more important than shipping features fast: a verifiable release rhythm. When testing, refactoring, and value validation run as one set within a two-week cycle, quality and growth move together.

In this post, I'll walk through how to run a two-week development cycle, and how to apply Acceptance Test-Driven Development (ATDD) at its core.

The Basic Structure of a Two-Week Cycle#

If you don't want two weeks to just slip by, you need clear jobs for the start, middle, and end of each cycle.

1. Cycle start — Lock in feature goals and acceptance criteria (AC)
2. Mid-cycle — Flesh out test scenarios for each feature
3. Cycle end — Run business tests and hold a retrospective

The key point is that every cycle ends with business tests. You spell out the test items within the milestone, and the cycle isn't done until both existing and new tests pass.

Test Gates: Never Ship with Defects#

Setting up gates that must pass before every release keeps your judgment from wavering.

• New tests pass — Tests for the features added this cycle
• Regression tests pass — Confirm existing features didn't break
• Clear defect tolerance criteria — Grade defects as critical, major, or minor
• Hold the release if a critical defect exists — Never ship in a defective state

The gate's job is to shrink the room for "this much is probably fine" thinking.

How to Apply ATDD#

ATDD (Acceptance Test-Driven Development) means defining requirements as acceptance test scenarios first, then implementing and verifying against those scenarios.

The big win here is lower communication cost. When business language and test language match, product folks and developers can read the same sentence and understand the same thing.

Refactoring Is Design Health Maintenance#

If you schedule refactoring as a separate task like feature work, it keeps getting pushed back. So you need to reframe it.

• Refactoring isn't feature work — it's the activity of keeping the design right
• Do small refactorings alongside every feature-level piece of work
• Tests act as the safety net for refactoring

With solid tests, there's no reason to fear refactoring. That's why the test gates above and refactoring come bundled as one set.

A Value Framework for Deciding What to Build#

When deciding what to develop, judge against three kinds of value.

1. User value — Does it solve a real problem?
2. Business value — Does it contribute to sustainable growth and revenue?
3. Personal/team value — Does it align with the philosophy we care about?

The order matters too. Build user value first, gather and evaluate the data, then connect it to business value. And beyond value for others, you also need to reflect the value you personally consider important — that's what makes it sustainable.

This Culture Is a Hiring Asset Too#

This way of operating is also an attractive selling point to outside developers.

• "Our team practices ATDD/TDD for real, in production work"
• "Service-centered decision-making and a testing culture are the core of our growth"
• "Join us and you'll learn product thinking, not just feature building"

Compared to a team that only touts feature velocity, a team that works in a verifiable rhythm is a better growth environment for developers.

Wrapping Up#

Try turning your two-week cycle into more than a deadline unit — make it a rhythm where test gates, ATDD, refactoring, and value validation all spin together. It may look a bit slower, but as defect-free releases stack up, that turns out to be the fastest path.

Your future depends on many things, but mostly on you.

— Frank Tyger