February 6, 2015

Requirements, Stories & Epics

Good requirements are critical to building quality software efficiently. Having shared strategies to define and document requirements helps users, subject matter experts, and developers build a shared understanding of what is needed.

Stories

User stories are a strategy for describing requirements for a small contained feature. By convention stories include a role, an action, and a reason.

As an AST I need the ability to see who changed a course plan record and when so I can resolve discrepancies correctly.

Ideally stories describe distinct deliverable functionality that can be translated to development projects which can be completed with a development cycle.

Epics

Stories will vary in size and scope. Big stories describe general needs and (hopefully) can be broken down into smaller addressable stories.

We refer to the top level stories as Epics. Epics may never be “done”, they can describe ongoing needs. Epics provide a way to describe overall organizational needs and give us a tool for prioritizing at high levels.

Prioritizing Epics and Stories and Work

We prioritize epics to develop a shared understanding of the goals and needs of the organization. We develop stories that describe contained achievable goals that support the epics. We map the stories to projects, units of work that can be achieved during a development cycle.

Those projects are prioritized on many factors including…

• importance of the epic
• importance of the story
• real world dates, events, and deadlines
• immediate value provided
• risk reduction
• ready to be worked on, dependencies are satisfied
• size of project, easier to schedule small contained projects

Karen and Paul will draft these priorities and then seek feedback in our cycle planning meetings.

A great article describing “story” and “epic” terminology”

http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes