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?

  • 2
    Anyone who uses the system is a user. Is the "Business Owner" using the system? Then they are a user. They have different requirements from the end-users, who do not want to use end-user analytics. Commented Dec 6, 2019 at 9:29

4 Answers 4


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:

  1. It identifies a collaborator who can help define the implementation details.
  2. It identifies a useful objective that constrains the solution space without being overly prescriptive about the implementation details.
  3. 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!

  • 2
    Thank you for the time it took to write all this out - it was very helpful Commented Dec 6, 2019 at 0:50
  • 1
    +1 for recontextualizing around the goal rather than the methodology. Business continuity has value; backups are a method; if you can provide the desired continuity, I don't care if you do it with backups or fairy magic. Specify what must be done, not how to do it.
    – MCW
    Commented Dec 17, 2020 at 12:27

Welcome to PM.

One of the most influent persons in this world (of Project Management), Mike Cohn, wrote an article about it back in 2015 you should definitely read with name Not Everything Needs to Be a User Story: Using FDD Features. Some of his articles were used to provide good answers to questions within this community and it also suits yours.

The article name mentions author's solution for such cases where the user is too far away - Feature-Driven Development (FDD).

As the author writes

An FDD feature is written in this format:

[action] the [result] [by|for|of|to] a(n) [object]

As examples, consider these:

  • Estimate the closing price of stock
  • Generate a unique identifier for a transaction
  • Change the text displayed on a kiosk
  • Merge the data for duplicate transactions

You have some great answers already, but I just want to add something. You say that your stories:

aren't really end-user driven in the traditional sense

I'm not sure that is the case for all the stories you list.

For example:

As a Business Owner I want regular database backups so that we can maintain business continuity

Yes, this is important to the business owner, but that is because of the impact it will have on the end users.

You could rewrite it as something like:

As an end-user I want to be sure my data is protected so that I don't lose access to the product or have to re-enter my details

Similarly for:

As a Business Owner I want end-user authentication so that only registered users have access

Your end users also want a secure service. This could possibly be rewritten as:

As an end-user I want to be sure my account is secure so that nobody else can access my information or make unauthorised changes

  • What is wrong with ascribing requirements to the Business Owner? That is who pays the salaries of the developers. The Business Owner or CEO is responsible for mediating between marketing and engineering. Marketing will say they want some feature to be able to sell the software. Engineering will say it will cost so much to implement. The CEO then goes back to marketing and says the price will have to rise by so much to pay for the feature-is it worth it? The CEO may also beat on engineering saying the feature should be cheaper to implement. Commented Dec 7, 2019 at 4:55
  • The concern is that it may create a disconnect from the customers. You might end up spending time and resources on something that the customers don't greatly value or alternatively you may miss out on an opportunity to build something they do value. By linking requirements to end-user value you help the organisation to think in terms of what their customers really value. Commented Dec 7, 2019 at 8:33
  • Hyperfocusing on the end user can also lead to lots of non-functional requirements being overlooked. The end user probably doesn't care about things like PCI compliance, SLA numbers, the MTF of an application server, how frequently an external firm audits app security, etc. I am not really a fan of user stories for that reason; I also feel like they rarely capture requirements with an adequate level of detail. Commented Dec 7, 2019 at 12:49

User stories are a tool for understanding and fulfilling user needs. I could change that last one to say "As a paying user, I want my logins secured so I don't get charged for unauthorized use of my account."

There are other mechanisms like the Definition of Done for quality concerns like availability, testing, etc.

Also, Scrum does not require the use of user stories, so if you want to add recoverability (which is what I would focus on over the backup itself), you don't have to use a user story to add that to the backlog.

  • 2
    As a way of improving your improvement, how about "I want my logins secured so I don't get charged for unauthorized use of my account"?
    – Todd A. Jacobs
    Commented Dec 5, 2019 at 19:15
  • On a separate note, there may even be multiple personae that have an interest in account security: the fraud department, the compliance department, the customer, the customer's spouse (who's the holder of the credit card on file), and so forth. Sometimes it's useful to have multiple stories when the framing or context of the use case is different. In this case it probably wouldn't be, but I can't help bike-shedding about this particular aspect of the user story approach just because this topic comes up so often in my coaching roles.
    – Todd A. Jacobs
    Commented Dec 5, 2019 at 19:16
  • 1
    @Todd First, I like your idea so I incorporated it. Second, I agree that there can be many stakeholders and there is a whole conversation that could happen around the difference between internal beneficiaries like a fraud department who actually gets real value from the work and internal stakeholders like product champions who are interested in the outcome on the end-user's behalf. It's always a bit of a balancing act in these questions on how far to dig in.
    – Daniel
    Commented Dec 5, 2019 at 20:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.