Identifying the Story's Primary Consumer is Acceptable
The term "user" in user stories is often better understood as an actor or role in a use case, or even simply as a value consumer. The primary goal of having a clearly-defined role in a user story is to frame the story to constrain scope. The secondary goal is to ensure that the user story is seen as a collaboration placeholder, rather than as an ersatz specification. With an identified consumer of the story, it becomes much easier for the team to know who to talk to about implementation details or acceptance criteria.
To make a long story short, there's nothing wrong with your stories from a purely pragmatic standpoint. However, they can be better if you leverage the "user" in the story format to improve context and collaboration.
Improving Your Stories
While your stories are likely actionable as-is, you can improve them with better framing and by creating collaborative opportunities. Let's look at an example.
Using the objectives outlined above, you might rewrite your first story as follows:
As a database administrator
I want to ensure the database can be recovered within 4 hours
so that we can meet our business continuity goals.
This story is likely to be superior to the original because:
- It identifies a collaborator who can help define the implementation details.
- It identifies a useful objective that constrains the solution space without being overly prescriptive about the implementation details.
- It provides context about why the story is useful, and this context can often guide the implementation choices and collaboration discussions.
Your other stories would likewise benefit from similar treatment. It's definitely worth spending a bit more time ensuring you've captured the right collaborators for a core story, as well as sufficient context to ensure the team is building the right thing.
Iterating on Features is Expected
If there are multiple roles or feature refinements, and a single story doesn't (or possibly can't) capture them all, you're often better off picking a basic use case and then iterating. That's what iterative development is all about! If you're using user stories, you should be improving on your features iteratively, incrementally, and empirically anyway. By taking an interative approach, you can focus on getting features done just-in-time and to a "good enough" level of quality, rather than trying to spec out a complex solution with big, upfront planning efforts that will generally over-constrain the solution space to no useful purpose.
When done properly, user stories are not just a different way to describe old-fashioned specifications. They represent a different paradigm based on collaboration and empirical control, and require a fundamentally different way of thinking about a problem domain.
Leverage user stories as conversation-starters and shorthand notes to feed your collaboration. Don't write detailed stories for stuff that's not currently in scope (YAGNI), but spend the time to decompose and identify the really important stuff during Backlog Refinement and Sprint Planning. When a given feature finally comes into scope as part of a cohesive Sprint Goal, it will be much more obvious whether you have the right who and what in your stories, and that will in turn be a better guide for the Development Team when they work on how to implement it during the current Sprint!
