Technical Analysis Before the Sprint: The 'Kitchen Prep' That Prevents Mid-Sprint Disasters
Summary
- No “We’ll See”: Kill ambiguity. If you don’t know how to build it, you can’t estimate it.
- QA First: QA writes test cases now, not later. They define the target we’re aiming for.
- Pre-Mortem: Find the landmines now, while they’re just drawings on a whiteboard, not bugs in production.
There’s a dangerous myth that Agile means “we just figure it out as we code”. That’s not Agile; that’s amateur hour. Technical Analysis is the kitchen prep. It’s where we chop the vegetables and measure the spices before the heat is turned on. If you wait until the sprint starts to ask “how does this API work?”, you’re already blocked. Get into the kitchen and prep your ingredients.
Part 4 of the Agile Series — The Complete Cheat Sheet.
The Process: Team in Control
This is the domain of the Engineers and QA. The Product Owner is usually not involved, or only joins on demand to answer specific edge-case questions.
The Goal: To remove all “grey areas” before Planning.
1. Technical Decomposition
The team looks at the requirements and breaks them down into technical tasks:
- DB Changes: “We need a new column ‘status’ in table ‘orders’.” -> Write this as a note on the Jira ticket.
- Refactoring: “The current ‘payment’ class is spaghetti; we need to extract a service.” -> Create a sub-task.
- API Contracts: Define the JSON request/response structure.
2. QA Involvement: Test Cases
QA doesn’t wait for code to be written. During this phase, QA writes the Test Cases based on the requirements.
- These test cases are shared with developers before a single line of code is written.
- This ensures developers know exactly what will be tested.
3. Handling Uncertainty: POCs
If the team says “We don’t know if this library supports X”, we don’t guess.
- We open a Spike/POC (Proof of Concept) task immediately.
- Someone writes a quick throwaway code to verify.
- If the POC fails or is inconclusive, the item is rejected from the upcoming Sprint.
Criticism & Reality: Is this “Mini-Waterfall”?
Agile purists might criticize this phase: “You are doing design before the Sprint, this is Waterfall!”
My Answer: Reducing risk is not Waterfall.
- It’s Optional: This phase is a set of training wheels. A mature team that knows the domain perfectly can discuss the “How” in 10 minutes during Grooming and skip this phase entirely.
- It’s Time-Boxed: This is not a weeks-long architecture board. It’s a focused brainstorm (e.g., 1 hour per sprint) to prevent the “We didn’t know the API was missing” excuse on Day 5.
- It’s Flexible: If a team is stuck in “Analysis Paralysis,” kill the meeting. But for complex systems, “winging it” in the Sprint is not Agile; it’s gambling.
The Bottom Line
Technical Analysis is where the real engineering happens. By the time we leave this phase, the Jira ticket should be full of technical notes, DB schemas, and test cases. The team should be confident enough to say: “We know exactly what to do.”