|
|
|
|
|
|
by jbreckmckye
3238 days ago
|
|
|
Why not just write, "We want to add the software version number to the dialog. We think they will then cite this when they raise tickets" ? At least in this form, you can expand on the context and justify it in depth. Also, user stories often phrase the context as a given when it's really not. In your example, it's an implicit premise that a version number may help. In mine, the writer admits scepticism and therefore invites the programmer to think up some better solution. |
|
|
* By having a premise, it forces you to question its validity up front (before any development work is done), getting rid of ambiguities early and having a shared understanding between business and technical team members (rather than the developer implementing what they think is a better solution, the product owner being unhappy with the outcome & only finding this out at the end).
* Using the format of "As a <type of user>, I want to <use a feature>, so that I can <achieve some value>" forces you to think about what user (customer/website editor/back office) gets what specific value (faster/cheaper/less error prone) from implementing some feature. By following the same pattern it makes it easier to compare unrelated areas.
I don't think the format is sacrosanct, but it's like any constraint you put on yourself (e.g. coding conventions) — if you find it hard to make a story work in that format, it's an indication that it may not be properly understood it really bringing value.