The Agile Persona Template That Ends Scope Arguments

Open your backlog and read the role clause on twenty stories. I will guess what you find: as a user, as a user, as a user.

The word carries no information. It cannot tell you what the person already knows, what they are afraid of, what device is in their hand, or how much patience they have left. And because it carries no information, it cannot help you decide anything — which is inconvenient, since deciding is the entire job of product ownership.

A persona fixes that, but only if you build it as a decision device. Most teams build them as marketing profiles instead: a stock photo, an age range, a paragraph about weekend hobbies. Those get printed, admired, and never consulted again, and after a while everyone concludes personas are theatre. They are not. The agile persona template below fits on one card, takes fifteen minutes to fill in, and settles arguments that have been running in your team for months.

"As a user" is a placeholder nobody ever replaced

The user story format — as a [role], I want [action], so that [benefit] — was designed with a specific role in that first slot. The role was supposed to change the design. A story for an administrator and a story for a first-time visitor describe different products even when the action is identical.

What happened instead is that "user" became the default, and the default became invisible. Once every story serves the same nameless person, every scope debate becomes an argument between two people's private mental images, and those arguments cannot be settled by evidence because nobody has said out loud what they are picturing.

I have watched teams spend six weeks building a configurable interface to serve the average of two user types who have nothing in common. It satisfied neither. That is what designing for "a user" produces: the average user, who does not exist.

A persona is a decision device, not a demographic

A persona is a short, evidence-based description of one type of person who uses your product — their goal, their context, their constraints, and what good looks like for them. It is not a market segment. It exists to make design and scope decisions easier by giving the team a specific human being to argue about instead of an abstraction.

The test of a persona is not whether it is vivid. The test is whether it settles decisions. If reading the card does not immediately close at least two open questions on your board, you wrote a biography.

What goes on an agile persona template

Roman Pichler's persona template for agile product management is the one I keep coming back to, because it keeps the whole persona to a single card. That size constraint is doing real work. A persona that runs three pages will not be read. A persona that fits on a card gets pinned above its column on the story map and consulted every time the team disagrees.

Six fields:

Field	What goes in it	Warehouse app example
Name and sketch	A memorable name and one line	"Marcus, second-shift picker, four months on the job"
Role / background	What they do, how experienced they are	Works a scanner gun for eight hours; trained for two days; not a computer user off the job
Goal	Why they come to your product at all	Clear his pick list before shift end without getting flagged for errors
Context / environment	Where and how they use it	Cold aisle, gloved hands, one-handed operation, spotty Wi-Fi at the back wall
Constraints / pains	What makes their job hard today	Cannot leave the aisle to ask a question; a wrong scan costs him ten minutes of backtracking
What good looks like	How they would describe success	"It told me what to do next and I never had to think about the app"

Keep each field to a sentence or two. Resist the urge to add a seventh field. Every field you add lowers the odds the card gets read at the moment it would have mattered.

Count the decisions one card settles

Read Marcus again and watch how many open questions close without a meeting.

Gloved hands means large tap targets and no long text entry. That is a design decision, made. Spotty Wi-Fi at the back wall means the app queues scans offline and reconciles later — an architectural decision, made, and one that would have been enormously expensive to retrofit. Not a computer user off the job means no hidden gestures, no jargon in error messages, and no assumption that he will discover a feature by exploring. A wrong scan costs him ten minutes of backtracking tells you exactly how much friction a confirmation step is allowed to add, and that error prevention beats error recovery here.

Four fields, four decisions, none of which were visible when the story said "as a user."

Now try the opposite direction. A team building a clinic scheduling tool had two personas: Dana, an office manager who lives in the tool eight hours a day, and Ray, a physician who opens it twice a week for ninety seconds. Every feature debate resolved instantly once both cards were on the wall. Keyboard shortcuts and bulk editing? Dana. Zero-training, three-tap flow with everything visible on one screen? Ray. Before the personas existed, that team had spent six weeks building the configurable interface I mentioned earlier, which served the average of the two and satisfied neither.

When personas conflict, choose — do not average

That is the rule most teams get wrong, so it is worth saying plainly. When two personas want opposite things, you do not split the difference. You decide whose journey this release serves, and you say so out loud where the team can see it.

Sometimes the answer is that both get served, in sequence: Ray's three-tap flow ships in release one, Dana's bulk editing in release two. That is a fine answer. What is not fine is a compromise interface that no real person asked for, chosen because deciding felt political.

How many personas do you need? For most products, two to four. One is usually a sign you have not looked hard enough — almost every product has an end user plus somebody who administers, approves, or supports them. More than five and nobody reads them, and you are probably describing variations of the same person rather than genuinely different people.

Personas are evidence, not imagination

A persona invented in a conference room is a shared guess wearing a name badge. It will still be better than "as a user," because at least it is specific enough to be wrong in public. But specificity without evidence is how a team spends a quarter building confidently for somebody who does not exist.

Build them from what you already have. Support tickets are the cheapest persona research in existence and almost nobody reads them in bulk. Sales call notes tell you what people say they want before they buy. Watching one person use your product for twenty minutes will teach you more than a month of internal debate. If you genuinely have no evidence yet, write the persona anyway — but label it a hypothesis on the card, in writing, and go get evidence before you build past release one.

The label matters more than it sounds. A card marked hypothesis invites correction. An unmarked card gets treated as fact within about three weeks, and by then nobody remembers that the whole thing was invented on a Tuesday afternoon.

The real test

Here is the one I use. Pin your personas above your story map. The next time your team disagrees about scope, do not argue the feature. Point at the cards and ask which of these people we are serving in this release.

Most scope arguments are persona arguments that nobody has named. Once the cards are on the wall, that becomes obvious in about ninety seconds — and the argument you were having stops being about opinion and starts being about which specific human being is on the other end of the decision.

Key takeaways

• "As a user" carries no information, which is why it cannot settle a single build decision.
• A persona is a decision device: if the card does not close two open questions, you wrote a biography.
• Six fields on one card — name, role, goal, context, constraints, and what good looks like.
• Two to four personas per product; when they conflict, choose whose journey the release serves rather than averaging.
• Build personas from tickets, calls, and observation — and label a persona a hypothesis if you have no evidence yet.

Frequently asked questions

What is a persona in agile product management?

A persona is a short, evidence-based description of one type of person who uses a product: their goal, their context, their constraints, and what success looks like for them. It is not a market segment or a demographic profile. Its purpose is practical — it gives a team a specific human being to make design and scope decisions about instead of an abstraction called "the user."

What fields belong on an agile persona template?

Six fields fit on one card: a name and one-line sketch; role or background; the goal that brings the person to the product; the context and environment they use it in; their constraints and current pains; and what good looks like in their own words. Roman Pichler's persona template for agile product management uses this structure, and the one-card limit is deliberate — longer personas do not get read.

How many personas should a product have?

Two to four for most products. One usually means you have not looked hard enough, since nearly every product has an end user plus somebody who administers, approves, or supports them. Beyond five, the personas stop being read and you are generally describing variations of the same person rather than genuinely different people with different goals.

What do you do when two personas want opposite things?

Choose one for this release and say so out loud. Do not average them. Designing for the midpoint of two personas produces a product that fits neither, because the average user does not exist. Often the right answer is sequential — one persona's journey ships in release one and the other's in release two — but the choice must be explicit and visible to the team.

Where do you get evidence for a persona?

Support tickets, sales call notes, and twenty minutes of watching one real person use the product will beat a month of internal debate. If you have no evidence yet, write the persona anyway but mark it a hypothesis on the card and gather evidence before building past the first release. An unmarked guess gets treated as fact within about three weeks.

Where the personas go next

In Module 1 of my User Story Mapping class you write two personas for a product you own, pin them above a map you build with your own team, and use them to draw the release line.

See the class