If people don’t “get” user story writing, try this simple exercise: Take a non-functional requirement and convert it into one or more stories by looking for the user(s). Here’s an example from a project I did a few years ago:
The Functional Spec included a non-functional requirement for an overnight batch run to create a particular database report. We looked for the users and discovered that this report was for only one person, who liked to begin each day by looking over yesterday’s figures. So we turned the requirement around and wrote it from that user’s point of view. Now we have a user story concerning this chap’s wish to read that report. It completely replaces the earlier non-functional statement, which was clearly a solution, not a requirement.
User stories also free the developers to be creative in providing a solution, because they are focused only on the business need and not on the analyst’s perception of today’s (or yesterday’s) technical constraints. On the project above it turned out to be easiest to build the report on the fly, incrementing it with every transaction throughout the day. This solution failed to meet the original ‘requirement’, but in fact over-delivered for the user, who was now able to view his figures at any time during the day.
Get in touch if your team would benefit from training in how to avoid this kind of mistake.