An overview of how to get from a concept to a set of stories that a technical team can
implement.

Introduction

One of the common problems faced by those new to Agile is how to get from concept to
stories that the team can implement. Although training courses often talk about how to
manage a story over the life cycle of a project, they fail to discuss how these are created in
the first place leaving those responsible for defining requirements wondering where to start.

Once reason for this is that every company/project is different. That said, the technique
described below has served this agile practitioner well.

Epics to User Stories

Agile features are traditionally described as stories. A story is a discrete piece of work that
can be tested and achieves something of business value. (E.g. validate a credit card). In the
early days of a project all stories will be Epics. In agile speak, an Epic a top level story that
describes a business requirement or activity at a very high level. These are iteratively
broken down into smaller stories (user stories) that the technical team will implement.

Find your Epics

A sure way to find a first cut set of Epics is to follow the business process – perhaps by
creating a UML activity diagram, value stream map or flow chart covering the whole
process. This works weather you are creating a new application or planning to extend an
existing production system. Even in the case of the former, you are likely to be integrating
with services or systems that are already installed and these should be included in the end to end process flow.

At each step in the process write a brief description of what you want to happen, why it needs to happen and who will do it (customer, admin clerk, xyz system). Where a step already exists, be sure to describe if /how it has to change as part of the project. Be suspicious if the work required cannot be summarised into Mike Cohn’s often used format As a <somebody> I want to <do something> so that <some benefit/outcome> .

Processes that are not performed by a human – e.g. an email server sending confirmation
emails – are to be regarded as a persona in their own right. This, however, may make
verification that the work has been successfully delivered more difficult; in the case of the
email server example, an email can be generated, however, if the output is pure data then it may need human inspection or an automated tool to evaluate test cases. It’s not important at this stage to worry about the how, just to have identified how you might test it or note it as an open question to raise with the technical team.

For each step you have identified, consider how the outputs from that step can be verified.
For example, the stock check step in an order process could be tested by creating a mixture of products that are in stock and out of stock on the test system.
Record your work in a spread sheet or tool such as Power Point to capture the Epics. Insure that every Epic has a number and if possible reference back to step(s) any supporting business process diagrams.

Refine your Epics

Having created your Epics, the next stage is to decompose these into smaller tasks where
appropriate (Even a simple project is likely to need at least two passes). Decompose each
Epic down into smaller steps. For example, a process step that states create customer account may have several smaller activities:

• Select a unique user name
• Enter address details
• Enter personal preferences

During this second and subsequent more detailed passes, you will find that you need to have more information to hand regarding business rules and example documents. If you have not already done so, this would also be the time to engage with business users, operations and other interested parties to confirm details of how the solution will work. Engagement can be through workshops, interviews, questionnaires – any mechanism that allows you to obtain more information from the user.

You may find that the detail phases throw up new Epics or a realisation that existing Epics
are wrong. That’s fine – change or throw away what you don’t need. At the end of each pass you should have a set of Epic’s, many or all of which will have candidate child user stories. It is vitally important that you are able to reference each candidate child story back to it’s parent Epic. (As the number of stories grow, so it can become less obvious which Epic acted as parent to the story). Each candidate user story can be tested against the INVEST criteria:

• Independent – once started be completed without other stories also being completed.
  Other stories being completed may be a pre-condition for starting a story, but once
  started the story must not depend on others before it can be tested.
• Negotiable – it’s not a contract – sufficient is known to understand what is needed
  without an excess amount of detail; room for discussion about the how and what in a
  planning meeting.
• Valuable – why it’s worth doing.
• Estimable – can be estimated
• Small – can be completed within the expected timebox length. If the project is likely
  to use two week development Sprints/Timeboxes, then the story must be one that be
  started and finished in that time.
• Testable – can be tested.

(TIP: Creating stories in PowerPoint means they can be printed as “hand outs” that can be cut up and stapled to a 6×4 card).

Sufficient Rigour

How do you know when you have done enough story refinement? When passes aren’t
producing anything new, you run out of time before the coders are ready to start or your
experience/but tells you the job is done. A pre-coding review with one or two
testers/developers will help you to determine if more work is needed.

No matter how many passes you take the likely hood is that more detailed implementation
stories will emerge when the team starts to consider how they will build the solution.
Sufficient rigour means doing enough to have a good understanding of the problem space but not wasting time going into fine detail. Fine detail is subject to change and is better tackled on a Just In Time basis.

NFRs, Deployment and Documentation and Other Miscellaneous Stories

Inevitably, project teams tend to focus on the business solution and technical implementation. Too often Non Functional Requirements (NFRs) stories are left out and become an inhibition at deployment time. The needs of Operation, Support and Deployment Teams are just as much part of the product as the needs of the sponsoring business user. Early engagement with these teams and consideration of their requirements will make the difference between an on time delivery and one that is late and botched.

Minimal Marketable Feature Set (MMF)

Before coding commences review the Epics and associated child stories to decide what will
be in the first release. Not everything can be included (agile differs from traditional methods by flexing features instead of time/cost/quality). The MMF represents the essential requirements that must be present to have a release that does something of value. To prevent over delivery Epics can be partially implemented (i.e. some of child stories are not needed for to achieve a basic release).

Where the project is likely to run for several months, create increments, each with their own MMF. Increments are candidate releases that deliver some business value. Even if the
increments cannot be released to production, you will have created a set of measureable
milestones. An MMF also helps to focus the technical team on an understandable and
attainable goal.

Once the MMF items have been identified, prioritise the stories. The MMF stories should be the first items to be implemented however the technical team, in discussion with the business users, may vary this to mitigate technical risks.

© Nigel Mossman, May 2012.