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.
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".
"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.
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.
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?
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.
Number of developer hours should be nearly nothing. A couple per week.
Done properly, these things should keep you from getting halfway into implementing something, having a question nobody thought of, and getting stuck. Then stashing your work and moving on to something else while the original feature lingers half-done or dies altogether, either way the timeline got blown.
This is only possible (the time savings I mean) if you have a PM or product owner -- making devs do that work is madness.
Yup, recently moved to a smaller team. We have reduced standup to once a week and combined the other ceremonies into a single meeting, although we do give slack status' the other days. Even something this small has been a tremendous boost on my productivity.
I have been slowly suggesting we get rid of pointing all together, but I don't think that will be easily won :p
I am a remote dev out of timezone, and give a yesterday/today standup summary in Hipchat every day. If everyone else did that, we'd all have ~10min more each day for actual work. It's super effective.
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.