[IshKebab]

I agree. Also the way user stories are written just makes me want to throw up. "As a user I want to open the about dialog so I can see the version number." Blarghf.

Why not just "Implement about dialog with version number.".

I'm pretty sure 99% of 'user stories' are just feature lists written in a really really awkward and annoying way.

[another-dave]

The point of the "narrative statement" is to show what value implementing a story will bring to help bring a relative priority order to things. Otherwise people keep championing their pet features, without focusing on _what's the point_ of this feature.

"As a user, I want to be able to find the full version number of the product to make it easier to get help when raising support requests".

This is now something we can argue about — is this story bringing more or less value than, e.g. setting reminders or 2FA?

If you write the narrative statements in a banal or glib way, just for the sake of them, then of course there's no point, but that's true of most processes — e.g. JavaDocs are a good idea in principle, but you can make them equally useless: "return Boolean: true or false".

[jbreckmckye]

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.

[another-dave]

IMO, the format is meant to do two things:

* 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.

[cormacrelf]

There is some merit in at least trying to think about your users at every stage of the design. Methodically putting the user in every sentence refocuses your work on what makes the experience better for them. You are right that making it super repetitive makes you filter out the bits about user interaction when you read a long list.

User stories are mostly there to frame progress only in terms of things your project owner cares about. If you talk to non-tech people describing their experience of a product, they don't just reel off a list of nouns at you. They say 'you can click on the little thing and it wiggles'. So this is how you should be reporting to your non-tech boss.

Don't say 'I made /timesheet/:id redirect to /timesheet/:id/slug-of-sheet-name', say 'Users trying to get back to a timesheet can just type some of the name in their browser's URL bar and it will show up'. Definitely don't say the word 'slug'. They will thank you for it.

[tootie]

The stories aren't just for developers. If business doesn't understand the intent, they don't understand the value and can't set priority.

[Domenic_S]

A user story is not a complete spec.

The requirement you wrote makes it easy to accept it as a complete spec (just implement this!), when it isn't.

The user story you wrote prompts more questions -- what's the dialog look like? Do we display the whole version number? Does the dialog contain anything else? How does the user close the dialog? Where does the user interact to open the dialog?

[talldan]

The biggest problem with user stories for me, is that the amount of text often ends up making the board view in JIRA hard to read!

[joshwa]

Number one thing I do-- titles need to be scannable:

Admin :: Roles :: Multiple Roles)

And the "story" part goes in the body:

"As an adminstrator I assign multiple roles to users so they have access to all the parts (and only those parts) of the application they need to do their job."

..with additional context, exceptions, rules, examples, etc, in the body.

[philliphaydon]

People use jira?