S for small

A good user story should be small. That's obvious to most people. Small stories have many benefits, tying back to the previous principle that states the smaller our user stories are, the easier it is to estimate. More importantly, discussing small stories is easy, whereas large, complex ones will confuse people and ruin the communication. There is a term for large user stories: they are called epics. We will have a section of them in this chapter, mainly so you understand the term, then we will see how to break them down into user stories following the INVEST principles. 

A story should be just big enough to solve an atomic problem for the user. This usually leads to user stories being buildable in a maximum of half the development time in a sprint. They should be built in a few days by the agile team. (Maximum 5 days for a 10 working day sprint.) If you aren't working on a software or aren't using an agile methodology, then the right size is the smallest size where you can't split it further, still conforming to the INVEST principles.

The shopping cart view conforms to the smallness principle, so is the pop-up newsletter subscription. The whole checkout process might not be small enough. However, I give you the most obvious, although often encountered example for a not-small-enough user story: As a manager, I want to be able to manage my webshop's backend. There are many issues with this user story, but the most obvious is the sheer size of it. Also, it does not contain the sub-tasks required, so the user story becomes terrifying.