Following the formal user story style:

As <user>, I want <goal> so that <benefit>.

Our team has found difficulties in expressing things where there is a desire by the system's owners to do something which negatively affects the user.

As an arbitrary example, let's say owner wants to have the system charge customers every time they check their email.

Following the formal style of user stories, you might write this as follows:

As a customer, I want to be charged every time I check my email so that the system owner can increase their revenue.

Obviously the customer has no desire to be charged; the story becomes jarring to read and the language is getting in the way of the facts.

How could the requirement be written differently?

  • 1
    Are you having a problem writing the story or creating something you don't think is ethical? – JeffO Feb 1 '12 at 12:49

If paying money affected customers negatively, they wouldn't be using that service. Don't worry about this. Also, users don't (usually) pay money because they want to help out system owners, but because they want some service in exchange, so your example should really be like this:

As a customer, I want to be charged every time I check my email so that I can get service X in exchange.

Also, user stories are written from the perspective of all user roles, not just end customers. Consider writing this one from the perspective of the system owner as another user role:

As a system owner, I want customers to be charged every time they check their email so that I increase my revenue.

A general advice: Focus on the positive part of the user story and don't overthink it. They should be simple. If the user story is very negative, without a way to avoid it, then the problem is with the conception of the system, and in that case it doesn't really matter what you write on your cards.

  • The danger with writing from the perspective of the system owner, is that all the stories essentially come from the owners and the value of the user portion of the story is diminished. – Paul Turner Feb 1 '12 at 10:18
  • @ProgrammingHero: That's only one alternative I suggested. :) – Goran Jovic Feb 1 '12 at 10:22
  • 5
    @ProgrammingHero I think you may be hung up on semantics. System Owner can be the owner of the system (Eg. Product Owner). This system owner can also be a unique user role in the software itself. The user story should be written against the role or user type that happens to be System Owner, where as System Owner the person is a person in the Product Owner role of a software development team, which is in reality complely different. – maple_shaft Feb 1 '12 at 12:03
  • 4
    @Programming Here: remember that the story exists to serve you - to tell you why the feature is needed and who it benefits. If it benefits the company, say so in the story so the team is clear on why the feature exists. The card exists for transparency among other things. Knowing you're doing something that does not benefit the user is a good thing. – Bryan Oakley Feb 1 '12 at 12:18

The <user> does not have to be the end user - it can easily be the business owner/system owner:

As a system owner
I want to charge customers
So that the business can pay my programmers
  • I don't think having the system owner as the user is correct; every story could be written from their perspective if this approach is valid. – Paul Turner Feb 1 '12 at 10:24
  • Also, my understanding was that the story is in reaction to something the user does (checking their email) rather than something the system owner does, so having it from the perspective of the user seems more correct. – JohnL Feb 1 '12 at 12:08
  • 4
    @JohnL: the story is not in reaction to anything. It's an explanation of why you are implementing the feature. However, even though it seems the user may not benefit, they usually do. Even in this specific case, they benefit because when you change them the company will be profitable, which enables the company to continue to provide the service to the user. – Bryan Oakley Feb 1 '12 at 12:21

User stories don't exist to fulfill some sort of methodology requirement. They exist solely to clarify what a team is doing, why they are doing, and who benefits from that. If you twist the words to obscure the meaning or fit some stringent requirement for what a story is supposed to look like, it serves no one.

So answer the question "who does this benefit" and "why are we implementing this" honestly. Your development team needs this information to do their job. Even if the story is negative from the user's point of view, that's valuable information.

That being said, what you describe sounds more like a use case scenario rather than a story. Perhaps if you reduced this down to smaller pieces it might be more clean who the owners and beneficiaries are. For example, the feature of charging for checking email has several components. At the very least there is a UI component and a back end component, and perhaps a business rule.

You might break your feature down into these stories:

As a provider of an email service, I want to collect a fee for each read email so that I can earn money and continue to provide and enhance the service

As a user, I want the collection of the email fee to happen automatically so that I can read my email without having to acknowledge each fee as it is collected so that my experience is more enjoyable.

As a user, I want to be able to easily review the terms of service and fee amounts so that I understand the fees that are charged so that I can feel confident that I am getting my money's worth.

As a user, I want the collection fee for reading email to be small so that I can afford to use this service

  • 2
    I like this answer -- methodologies exist to build something. When they become dogma to be blindly followed, they are not longer serving there intended purpose. – Jay Elston Feb 1 '12 at 16:22

I agree that writing it in terms of the system owner seems wrong, because the system owner doesn't initiate this story - the user does, when they check their email. But I don't think you need to talk in terms of what the user wants, but rather what they expect to happen.

As a customer
When I check my email
I should be charged
So I continue to recieve Service X

The user would expect to be charged because you've outlined your payment plan to them.

  • 3
    It doesn't matter who "initiates" the story. The point of the story is for the team to understand the business value of the story. Sometimes the business value is to improve the customer experience, sometimes it is not. Be honest. It's not like the customer will see the card. The goal is to make sure the team is clear on why you are doing something. If the reality is, you're doing it to extract money from the user, say so. However, if the real goal is to stay in business so you can serve the user, say that. – Bryan Oakley Feb 1 '12 at 12:22
  • 1
    If this is how you were taught to write user stories then I am sorry to inform you that you were misled. A user story defines what a user needs or wants not what they expect to happen. The fact that charging for email occurs is simply a given. As a user I NEED to be charged so that I CAN check my email. This answer is factually and unequivocally wrong and I suggest deleting it. – maple_shaft Feb 1 '12 at 12:46
  • I guess I misunderstood then though I would suggest just adding that as your answer. I appreciate being set right, the downvote not so much. And I think it does matter who initiates the story because that's how I know what stories I'm dealing with right now. There's no way I can keep them all in my head at once, so to find out what happens when a user checks their email, I go to the story beginning with As a user, when I check my email... If I can't reliably do that then user stories are fundamentally broken. Sorry. – JohnL Feb 1 '12 at 12:58
  • 2
    @JohnL: What you are describing sounds more like use case scenarios than user stories. Both formats are OK for describing software requirements, use whichever works better for you and fits into your development workflow in a better way. – Goran Jovic Feb 1 '12 at 13:40
  • 2
    Goran and Bryan make excellent points. It sounds like you are dealing with use cases because user stories don't benefit you. These things are supposed to help your project succeed, if you feel that they are in general an overall hindrance then use cases and user stories probably are of little to no benefit to you and you shouldn't force yourself to use them. This is a perfectly legitimate scenario when the actual business logic, complexity and user perceived value of your software are so low that user stories are either sparse or common knowledge. – maple_shaft Feb 1 '12 at 14:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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