User Stories at Work

A brief guide to User Stories as practiced by The SilverLogic.

While some of the formatting and terminology may seem to be overkill or touchy-feely, Agile (the project management methodology for which User Stories were devised) is widely adopted and proven -- Agile is used by most development agencies worldwide and has increasingly seen adoption in other sectors in which time estimates often aren’t feasible, such as law firms and ad agencies. We think of User Stories having the following parts:

Stories have a Name

A story name is a unique description of the overarching functionality addressed so that both developer and client can grasp it.

Stories generally describe platform, actor, function, and value

As a Billing Manager (Actor), on the billing manager admin site (Platform), I would like to input details in the Job (Function) in order to generate an invoice PDF (Value)

As our work tends to take place on the web or mobile platforms and serves some valuable function for some actors on the platform, we put together these terms to make an awkward-sounding sentence as a guide for our work. The sentence helps us tell the “story” of that feature or functionality, offering rough context to all parties concerned regardless of technical or industry knowledge.

Stories have Acceptance Criteria

Acceptance criteria are the meat & potatoes of the story -- what the developers pay the most attention to during development, and what clients use as a guide when confirming the completion of work. Having clearly defined Acceptance Criteria before estimation and approval removes ambiguity and prevents later disputes between developer and client on how the scope of work was interpreted.

Stories have a level of complexity

We use story points as a measure of complexity and in some cases, uncertainty. We use Fibonacci numbers (1, 3, 5, 8, 13, et cetera) as point values because complexity in software development (as well as in many natural and mathematical phenomena) often scales within the Fibonacci scale. Asking a single developer to estimate a story in hours alone is fine, but with a team, the experience and technical knowledge of the individual members handling the work will have a considerable bearing on hours spent on a given task.

Stories belong to Epics

Epics are a way for us to categorize stories by theme. They're defined by the development team in order to group similar stories together.

Stories are worked on in sprints

A sprint is a development cycle. A group of stories is committed to by the team over a given interval. Common sprint lengths are 1-2 weeks, but some might be longer or shorter.