There was a time I believed that if I just wrote a perfect spec—everything would go smoothly. The devs would build exactly what I envisioned. QA wouldn’t miss a thing. The product owner would nod in agreement, and we’d launch on time. That fantasy lasted about two sprints. I Was Trained to Believe Specs Were Sacred I Was Trained to Believe Specs Were Sacred Back when I started out as a BA, we were taught to treat documentation like gospel. You wrote it all down—every scenario, exception, flow, dropdown option, tooltip. The longer the spec, the more “complete” it was. If it made it to 20 pages? Even better. every scenario, exception, flow, dropdown option, tooltip I once spent three weeks writing a spec for a search filter. No one questioned it. That was just the norm. Then Agile Happened—And My Confidence Cracked Then Agile Happened—And My Confidence Cracked Agile hit like a cold shower. Suddenly we were in sprint planning talking about “just enough” documentation. Stories were short. Acceptance criteria were lean. My 20-page documents became the elephant in the room no one had time to read. The first few sprints? Painful. Dev asked me things that werealready in the spec. already in the spec QA missed stuff because they were waiting for a walkthrough I didn’t have time to give. And I kept thinking:“Why is no one reading this?” “Why is no one reading this?” The truth? They didn’t need to. What they needed wasme, in the room, talking with them—not hiding behind a Google Doc. me My Wake-Up Call Came in a Retro My Wake-Up Call Came in a Retro I’ll never forget this. In a retro, one of the devs (very kindly) said: “We appreciate the effort, but the spec is too much. We’d rather walk through the story with you and get clarity directly.” “We appreciate the effort, but the spec is too much. We’d rather walk through the story with you and get clarity directly.” That one line shifted everything for me. I realized I wasn’t writing specs for them—I was writing them for me. To feel prepared. To feel useful. To prove I was doing my job. them me But in an Agile world, usefulness doesn’t come from a polished doc. It comes from creating shared understanding. creating shared understanding. I Burned the Spec—and Found Something Better I Burned the Spec—and Found Something Better After that retro, I tried something radical. I replaced a full-blown spec with: Three user stories
A sketchy whiteboard diagram
One 30-min conversation with the team Three user stories A sketchy whiteboard diagram One 30-min conversation with the team That was it. It felt risky. Like showing up underdressed to a formal party. But the team got it. They asked questions. They suggested ideas. QA chimed in with edge cases I hadn’t thought of. And the feature shipped—faster, better, and with less friction than ever before. What I Use Now (Instead of Specs) What I Use Now (Instead of Specs) 🧩 User Story Mapping— For seeing the flow, not just the features🧠Personas— To anchor decisions in user goals✅Lean acceptance criteria— So “done” is clear, but not rigid🎤Team conversations — Because no spec beats a 15-min talk User Story Mapping Personas Lean acceptance criteria Team conversations And sometimes… I still write things down. But not as a crutch. As a compass. The Hard Truth: Specs Made Me Feel in Control. But They Weren’t Saving Me. The Hard Truth: Specs Made Me Feel in Control. But They Weren’t Saving Me. Specs gave me the illusion of safety. I thought they would shield me from mistakes, misunderstandings, and scope changes. But all they really did was delay reality. What works now is different: I talk more. I listen harder.
I stay involved through delivery, not just at kickoff.
I let go of perfect. I aim for progress. I talk more. I listen harder. I stay involved through delivery, not just at kickoff. I let go of perfect. I aim for progress. Final Thoughts: You Don’t Need a Spec. You Need a Seat at the Table. Final Thoughts: You Don’t Need a Spec. You Need a Seat at the Table. If you’re a BA struggling to let go of “the way it used to be,” I get it. I was you. But Agile doesn’t need scribes. It needs connectors. People who create alignment, not attachments. People who know how to lead in a room full of change. So write if you must. But don’t hide behind it. Be the reason the team builds the right thing. right

This story contains new, firsthand information uncovered by the writer.

Google

Here's Why Your Backlog Is Really Overloaded

Confession: I Used to Think Specs Were Everything. Agile Broke Me (and Made Me Better)

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Agile is Chaos. But There’s a Way Through.

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

10 Product Development Traps

Agile is Chaos. But There’s a Way Through.

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

10 Product Development Traps

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps