Thoughts on using user stories to define business/platform needs?
I'm very accustomed to user stories for end-user driven features. But if starting a project from scratch, does it make sense to treat the business owners as users and define their needs that way too? Some examples
As a Business Owner I want regular database backups So that we can maintain business continuity As a Business Owner I want end-user analytics So that we can know how our platform is being used As a Business Owner I want end-user authentication So that only registered users have access
Things like these are obviously features that a dev/devops team has to build, but aren't really end-user driven in the traditional sense that I think about for user stories. Thoughts?
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!