To avoid Big Bang integration and delivery right at the end that we get with waterfall and Water-Scrum-Fall, we have to change the way we do requirement gathering, analysis, and design. The aim of a User Story is to break requirements down into discrete chunks of work that will realize some business value in their own right. While it's not always possible to deliver a single User Story in isolation, the aim is to make them as independent as possible.
In fact, independent is the first attribute of the mnemonic INVEST, which we use when discussing the attributes of a good User Story. The letters of INVEST stand for the following:
- Independent: Avoid creating dependencies; if we have dependencies between User Stories, we'll create unfinished work, meaning we'll have to wait for other work to complete, before what we're working on can be delivered. This can, and will, create a house of cards as far as delivery is concerned. This is a crucial mindset shift when switching to User Stories and is important to get right.
- Negotiable: In this collaborative approach to building software, everything is negotiable. If the Development Team can see a better way to write the User Story or its acceptance criteria, they should negotiate with the Product Owner or vice versa.
- Valuable: Each story delivers value which contributes to the overall business objective. Ideally, this should be of tangible value to our customer - something they can see and use. If it doesn't have tangible value, then we're breaking one of the Agile principles: delivering working software frequently.
- Estimable: There is just enough information in the User Story for it to be estimated by the team. If the User Story isn't clear or well defined, the team will struggle to estimate it and it will require a conversation to get a clearer picture.
- Small: To give you a gauge for the correct size of a User Story, as a rule of thumb a full-size Scrum team is aiming to deliver five stories per Sprint. User Stories break requirements down into small chunks, which if done correctly can increase the flow of work and help aid prioritization, which in turn will help us deliver value sooner.
- Testable: Acceptance tests can be written and carried out against the acceptance criteria that tell us if the User Story is completed and the requirement is fulfilled.
Epic User Stories: Sometimes you'll hear the word epic being used to describe a User Story. If you're a literature fan and have read poetry like Beowulf, you'll understand what we mean by epic—it's not small.
We use the word epic to refer to a high-level User Story or feature set that describes a wide-ranging set of functionality. More often than not, stories of this magnitude will need to be broken down into discrete chunks of value so that we can deliver them incrementally.
We use the word epic to refer to a high-level User Story or feature set that describes a wide-ranging set of functionality. More often than not, stories of this magnitude will need to be broken down into discrete chunks of value so that we can deliver them incrementally.