Epics and personas: turning a vision into the first backlog

A vision fits on a card. A backlog does not. Somewhere between "families can book a tutor in minutes" and a list of items a team can start tomorrow lies a gap, and teams cross it badly in two ways: by writing three hundred stories nobody will build, or by building without writing anything. Epics and personas are the tools for crossing it in between.

What an epic is

The Scrum Guide has no epics. Its Product Backlog is an ordered list of items that become smaller and more precise through refinement, and it leaves the sizes and the vocabulary to the team. An epic, in common use, is simply a large item early in that refinement process.

The SBOK® Guide gives it a definition and a process. Epics are written in the initial stages of a project, when requirements are high-level or product descriptions are broad. They exist as large, unrefined user stories in the Prioritized Product Backlog, and they help the Product Owner and stakeholders plan releases, order high-level requirements and shape an overall roadmap. As the Product Owner gets more clarity, each epic is broken into smaller, more granular user stories. An epic contains one or more of them.

Two points follow from that description.

• An epic is a placeholder, not a promise. It says "there is a body of work around this need". It does not say how big it is or when it will be done.
• It is replaced by stories as it nears the top. The SBOK says stories need to meet the Definition of Ready and be estimated before they come up for an upcoming Sprint. The Guide says the same thing in plainer words: items that can be Done within one Sprint are deemed ready for selection.

Our post on user story anatomy covers what the small items look like.

Finding out what users need

Epics come from conversations with the people the product is for. The SBOK lists five techniques, each suited to a different question.

• Interviews. One person at a time, to understand needs, expectations and their view of the product, and to get their commitment. The SBOK says time spent interviewing users and customers helps ensure that epics align with the vision.
• User group meetings. Gatherings of the people who will use the product, giving the Product Owner first-hand information about expectations, helping to formulate acceptance criteria and creating buy-in. The SBOK says they prevent the expensive rework that comes from unclear expectations.
• Focus groups. Guided sessions where people give opinions, ask each other questions and refine ideas. Useful for new concepts and for settling disagreements.
• Questionnaires. A cost-effective way to get statistics from a large number of people, though the SBOK says they need careful design to avoid error and bias.
• User story workshops. A facilitated session with the whole core team, and sometimes stakeholders, to prioritise requirements, share a view of acceptance criteria and make sure the items describe functionality from the users' point of view. The SBOK notes they are also good for team building and for preparing Sprint planning.

You rarely need all five. Interviews and a workshop are enough for many projects, and a questionnaire helps when the audience is large and varied. What matters is that the people who will use the product are heard before the backlog is ordered.

What a persona is

A persona is a fictional character who represents a real group of users. The SBOK describes personas as highly detailed fictional characters, representative of most users and of stakeholders who may not use the product directly. A persona gets a name, preferably a picture, and specific attributes: age, environment, interests, goals, and perhaps a quote that sums up what they need. The Product Owner uses personas to understand needs and order features.

The value is practical. "The user" is nobody, and a team that argues about what "the user" wants is arguing about itself. A persona such as a working parent who books lessons on a phone in the evening gives the team something concrete to ask: would that parent notice this? Would they pay for it?

Keep personas honest. Build them from what you learned in interviews and research, not from assumption, and keep to a handful. Six personas become a cast nobody remembers. Revise them when the facts change.

From epic to stories

Here is an invented example for a library room booking system. After interviews with staff and members of the public, the Product Owner writes four epics: find a room, book a room, manage bookings, and run the branch (staff tools). Two personas emerge: a community group organiser who books monthly, and a branch librarian who handles disputes and double bookings.

"Book a room" is too large for a Sprint. The team splits it by outcome, which gives stories like "see which rooms are free on a date", "request a room for a time slot", "get a confirmation message", "cancel a booking". Each can be ordered and sized. The epic is not deleted; it remains as the heading under which the stories sit, which keeps the larger purpose visible.

This is the kind of decomposition refinement handles, and the Guide has no rule about when to do it. The sensible moment is as an epic approaches the top of the backlog. Splitting everything immediately spends effort on details that may never be built.

Scope boundaries

Gathering needs produces more than a team can build. The vision, the budget and the date impose a boundary, and the epics that fall outside it need to be recorded, not forgotten. A short list of what is deferred, and why, gives the Product Owner something to point to when a stakeholder asks. It is also honest: the Sprint Review is the wrong place to discover that nobody agreed what was out of scope.

The Guide's description of the Product Owner as one person who orders the backlog, and the SBOK's emphasis on stakeholder buy-in, point to the same practice: decide visibly, explain why, and keep the deferred items where they can be seen.

Common mistakes

• Designing the solution in the epic. "A calendar page" is a design. "Members can see availability" is a need.
• Writing every story up front. It looks productive, and most of it will change.
• Personas from imagination. Invented personas confirm what the team already believed.
• Epics that never end. An epic should be finished by its stories. If it has no end, it is a theme or an area of the product.
• One stakeholder's wish list. Epics should reflect what several kinds of user need, not one voice.
• No record of what was left out. The next request will reopen the argument.

How to practise it

In the simulator, the fourth step is a round-table workshop that turns the vision into epics and personas, and the Sponsor pushes for a feature that may not belong in the first release, so you decide where to draw the line.