I don’t use stories for work management either. Stories flow through the production system only as a side effect of their work items flowing through the system.

Stories aren’t descriptions of work, so they aren’t eligible as work management artifacts.

They inform the people doing the work, giving them (hopefully) an understanding of how they benefit the lives of their users with the software that they’re making.

Thanks for going into practical details that are hard to come by. And great to see additional wisdom the feedback too.

If you can express user stories with as little mention as as possible of any software, then you’re getting closer to the purpose of user stories, which isn’t to specify software but to communicate a contextualized description of a problem.

So, instead of: As a nurse I need to be able to set my default location so that I am viewing my preferred data when I log in to the Nursing Station app.

Try: As a nurse I view my preferred data in order to pay attention to {ah ha! something is missing in the analysis! the root cause/motivation!}

There are a handful of weaknesses in Scrum orthodoxy surrounding user stories and contextualized, user-centric design.

Instead of thinking wishy-washy geek distractions like “feature” and “business value”, consider the user’s goal in the work, and the motivation for the goal. This leads to a better analysis of context, which inevitably leads to systems that are a better fit to the task for having more user context communicated through user stories.

My user story format is:

As a [role] I want to [goal] so that [motivation]

I try to drop the “want to” filler and see if I can get right down to an imperative expression of what “I do”, rather than the passivity of something I “want to do” or “need to do”.

The goal is this: As a user, I tell you what I do so that you build software to support what I do.

The goal of user stories isn’t to describe software or features, it’s to communicate the context of people, their goals (the work they are called to do) and their motivations for doing it (context).

Also, the INVEST model is shaky at best. It’s an elaboration on user stories that Scrum added that is only useful in specific contexts.

User stories do indeed have dependencies when they’re used to sequence and schedule work. Which is why I personally don’t use user stories as work items, but as bearers of context to work items.

So, how do you communicate the specifics of logging in and the default location that are essential to your user story above? Flip the card over and write those details as acceptance criteria. Or, if you’re familiar with Context Specification, you can use it.