Scrum Core Principles - Epics, Stories & Iterations

Epic and story management

See

User Story

A user story represents a single piece of functionality, generally written in easy-to-read language from the users’s perspective. They are the main way that Scrum projects are defined and worked on.

In ScrumDo, we represent a story as a single card on the scrum board, or as an entry in the iteration view list.

I – Independent. We want to be able to move stories around, taking into account their relative priority. This means stories are easiest to work with when they are independent.

N – Negotiable. Stories are not an explicit commitment to produce certain features, but a framework for ultimately defining what to produce for the end user.

V – Valuable. A story needs to be valuable to the end user. Development issues should be framed in a way that illustrate why the end user would perceive them as important.

E – Estimable. We want stories to be estimable, otherwise they’re never likely to be tasked for development. Whether a story is estimable is a function of being negotiated (you can’t estimate what you don’t understand), a function of size (bigger stories are harder to estimate), and a function of team experience. Though estimation takes on less importance in a Scrumban environment, the same factors that allow for estimation help produce higher-confidence in the probabilistic forecasting methods Scrumban employs.

S – Small. Stories should be small – no more than a few person-days of work. Above this size it’s almost impossible to know a story’s full scope.

T – Testable. Finally, we want stories to be testable. If a story isn’t testable, you can’t really determine when it’s done. Test Driven Development has shown us how actually writing the tests early helps us know whether the business goal is met.