Fifty Quick Ideas To Improve Your User Stories

if a team passively receives documents in a hand-over, regardless of what they are called and whether they are on paper, in a wiki or in a ticketing system, that’s not really working with user stories. Organisations with such a process won’t get the full benefits of iterative delivery.

A story card is ideally just a token for a conversation. Assuming the information on the card is not false, any of the formats is good enough to start the discussion. If the information on the card is false, they are all equally bad.
[...] not the only way to start a good conversation. As long as the story card stimulates a good discussion, it serves its purpose.

Focus on the problem statement, the user side of things, instead of on the software implementation. The way to avoid trouble is to describe a behaviour change as the summary. For example ‘Get a profit overview faster’, or ‘Manage deliveries more accurately’.

In essence, translating Brinkerhoff’s idea to software means that it’s not enough to describe just someone’s behaviour, but we should aim to describe a change in that behaviour instead. [...] Capturing a behaviour change makes a story measurable from a business perspective, and this always opens up a good discussion.

Good example of delivering value fast without having to actually write new software.
Lateral Thinking

For example, a team we worked with had several weeks of work planned to enable traders to sell a new category of products, but it turned out that they could start to trade by logging purchase orders in Excel. The Excel solution did not deliver the final speed or capacity they needed, but traders started selling several months sooner than if they had to wait for the full big-bang deployment to production, and this had immense business value for the company.

But once we have settled on the best solution, the story description should be clear about exactly how the system functionality or business rules will differ between now and when the story is implemented.

Because teams primarily aim to create something small, instead of something valuable, they end up with a bunch of small stories that are too disconnected from what business sponsors care about. [...] Ultimately, this can lead to business users not really caring about individual stories, and waiting for a larger batch of work to be ready for testing,

Stories shouldn’t be small because they need to fit into an iteration, but because the world shouldn’t end just because a story turns out to be wrong. Stories are based on assumptions about business value, and those assumptions might turn out to be right or wrong.

The key questions for story sizing shouldn’t be about the iteration length, but about how much business stakeholders want to invest in learning whether a proposed change will actually give them what they assumed.

Small user stories can help product managers discover what really needs to be built without rushing too far forward under unvalidated assumptions, and help business sponsors manage their investment in software and get the most out of it. That’s how we should sell them, not as small chunks of work.