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.
Stephen
December 13, 2011
This is whole concept of User Stories is nuts – providing ambiguous desriptions of requirements to development and expect them to deliver what the customer wants!! really!! – get real… you must discuss and model the customers requirements and produce a Business Process Diagram (BPD)/ Use Case (high-level at least) and then a flow of events – its been my experience that gaps in functionality and poor customer satisfaction arises from poorly spec’d requirements and leaves you open to scope creap whereby the functional requirements from an users perspective are not met because the user story is not completely fleshed out. User Stories are ONLY useful if considered as a high-level 4-line paragraph that descripts a use case. Modelling BPD’s and Use Cases ensure that the complete end-to-end view of a customers requirement can be met – a small paragraph doesnt achieve this.
Steve