What Professional RE Looks Like for Your Team Today

It's Thursday, 9:50 AM.

Refinement starts in ten minutes. The PO opens Jira and sees three stories at the top of the backlog. No acceptance criteria. She knows roughly what these features are supposed to do - she was in the call when the stakeholder described them, three weeks ago. She starts typing.

She's not cutting corners. This is just what Thursday morning looks like.

In the last lesson, we named this: specification work, happening implicitly, under time pressure, with no shared standard for what good enough looks like. And we looked at why teams do all three activities - Elicitation, Specification, Validation - without owning any of them. What I want to show you now is what it looks like when that changes. Not a different methodology. Not a new role. The same three activities, practiced as a craft.

The difference isn't whether you do them. It's whether you know you're doing them.

What craft looks like in elicitation

When elicitation isn't owned by anyone, it's reactive. A stakeholder mentions something in a meeting. Someone fills in the gap two weeks later, in Slack, when it actually matters. The question that needed to be answered in week two gets answered in week five, when someone starts building and realizes they don't know.

Elicitation done deliberately works differently: before the story gets written, there's a question to answer first. Not "what should this feature do?" - that's too broad. The specific question is: what do I not yet know that would change how this gets built?

That question is specific enough to change the shape of the whole conversation. Instead of presenting a requirement and asking for confirmation, you're probing for the thing that hasn't been said yet - the edge case the stakeholder has in mind but hasn't mentioned, the constraint that changes everything once someone starts building.

When I started doing this deliberately, I was surprised how often the first answer to any question wasn't the real answer. Stakeholders know what they want. They don't always know how to describe it in a way that survives a sprint cycle.

Specification, practiced deliberately

The PO typing acceptance criteria ten minutes before refinement isn't doing specification poorly. She's doing something different - she's translating her own mental model into text, in isolation, under time pressure.

Specification as a craft is a different activity. The goal isn't to write down what you know. It's to produce a description precise enough that two people who read it independently build the same thing - and a third person can verify, without ambiguity, that it was built correctly.

That precision doesn't come from writing more. It comes from asking: if a developer built exactly what this ticket describes - nothing more, nothing less - what would I see in the sprint review that I didn't expect?

The answer to that question is the edge case you haven't written down - the interpretation that's obvious to you and invisible to the developer, sitting in your head and not on the card.

A team that practices specification systematically treats these questions as a normal part of refinement, not as a sign that the story wasn't ready. They surface before the sprint starts. Not every time. But the instinct is there.

Validation, and why later is expensive

Most teams validate at the sprint review. The stakeholder sees the feature for the first time, gives feedback, and the team updates the backlog. This is better than nothing.

What it isn't: early enough to be cheap.

Validation as a craft asks the same question earlier - before development starts, not after it ends. Can someone describe what we'd have to see to call this done, in a way that the stakeholder would recognize? If not, the story isn't specified - it's a guess with a due date.

I've started asking this question in refinement: "If a developer built exactly what this ticket says, and showed it to you in the sprint review - what would make you say it's not quite right?" The answers are usually immediate, specific, and missing from the ticket.

That conversation, in refinement, is cheaper than another sprint.

The training gap

There's a reason most POs don't practice RE as a craft: they weren't trained to.

A CSPO course teaches backlog management, stakeholder prioritization, sprint planning, product vision. It does those things well. What it doesn't teach is how to know whether a requirement is mature enough to be prioritized in the first place - because that's not the PO's job as Scrum defines it. The PO manages the backlog. The implicit assumption is that the backlog contains things worth managing.

That gap isn't a failure of the certification. It's doing exactly what it's designed to do. But it means the craft of elicitation, specification, and validation gets picked up through experience - through enough sprint reviews where the stakeholder said "not quite," enough times that you started wondering whether the problem was the feature or the ticket.

A team that's never addressed this gap can run a perfect sprint on a story that was never fully understood. The velocity metrics look fine. The burndown is clean. The story is delivered on time, accepted in the sprint review - and two sprints later it's back in the backlog with a comment: "needs rework." Not because the team failed to deliver. Because the story wasn't ready when it entered the sprint. The process worked exactly as designed. The requirement was the problem, and the process had no way to see it.

Most POs know how to prioritize. What the certification doesn't prepare you for is recognizing whether a requirement is actually ready to be prioritized in the first place.

That distinction - between managing work and knowing whether the work is ready - is the gap I wish someone had named for me ten years ago.

Where does your team actually hurt?

The question I hear most often here: "So where do we start?"

It depends on where the pain is - and there's a way to locate it.

If your stakeholders regularly say that what was delivered doesn't match what they asked for - the gap is in elicitation. The understanding isn't being shared before the work starts. Your entry point is learning to surface what hasn't been said yet, before the story gets written.

If your developers frequently ask for clarification mid-sprint - the gap is in specification. Stories are entering the sprint without enough shared understanding of what done means. Your entry point is learning what makes a story sprint-ready versus what makes it a question in disguise.

If sprint reviews regularly produce mild surprise rather than genuine satisfaction - features accepted, but the stakeholder adjusts their expectations on the spot - the gap is in validation. The feedback loop is too late. Your entry point is pulling validation earlier, into refinement, before implementation starts.

Most teams have more than one problem. But one usually hurts most.

That team is called Kira Labs - four people, a first prototype, a lot of user feedback, and no structured requirements process yet. They're who you'll follow throughout this course. You'll see what implicit RE looks like at sprint level, and what changes when it becomes explicit.

Which sprint are you in right now - and what was the requirements decision that brought you here?

There's no input field. No right answer to compare against. The question is a diagnostic, not a test - and the answer belongs to you.