I have a problem with user stories

I admit it. I have a problem with user stories. Not with the Actor/Narrative/Benefit syntax or the idea of adding acceptance criteria or the idea of valuing conversation over documentation. I love all that. I have a problem with the name “user” stories.

I’ve been applying Agile principles for about ten years now and working in sprints for two years. However, I am not an Agile or Scrum guru, so I’m more than happy to be challenged by those who are.

My experience of working with Project Managers and Scrum masters is that they are very focussed on the delivery of a software solution; so much so that they don’t stop to consider that business architecture is not just about their software delivery project. In particular, they are focussed on what users want. My experience as a business architect tells me that what users say they want is not necessarily what the business needs and solving the problems of one user (or community of users) might well cause problems for people elsewhere in the business.

But it’s not just that. The word “user” constrains our thinking. Not all those who have a stake in the successful implementation of software are going to be users of that software. For example, take the owners of a particular business policy. Those stakeholders care about the decision logic behind that policy. They care that it is modelled accurately, tested thoroughly, understood universally and executed consistently. They care that any software that automates the decision logic does so correctly every time it executes. However, they themselves may well not be users of that software and yet they are the key stakeholders in the narrative of the story.

I still come across user stories of the following pattern:

As a [user role], I need to do X, so that X is done.

I do hope you can see the problem here: a mere restatement of the narrative does not articulate the business benefit. Users often cannot articulate the business benefit of taking an action because they are not the ones who are ultimately accountable for that benefit. They are merely responsible for taking an action on a screen that is supposed to result in that benefit. Here’s a tip, if robotics software could do the user’s job, then the user is probably not the right person to be asking about the business benefit.

In fact, I like the following format, as proposed on Crisp’s Blog:

So that [business value], as a [role], I need [narrative].

What’s more, not every business need requires a software or hardware solution. Some needs may be satisfied with changes that are procedural, organisational, location, staffing in nature or some other type of change.

Does focussing on the users of the software, rather than those who are ultimately accountable for the business benefit, cause us to fail to fully understand what that benefit is and why it is important to the business? I don’t know of any data that can answer that question definitively but I think the answer is “Yes” in at least some cases. This is why, as a business architect, I prefer to think of “business stories” rather than “user stories” and when the business person I am speaking to cannot articulate the business benefit, then I am speaking to the wrong stakeholder.

What do you think?

Kind regards.

Declan Chellar

4 comments to I have a problem with user stories

  • Bharathi

    Hi declan

    I am almost agreeing to your thought perspective on business stories or capability story ( how I have seen it) and I always define it with as a sponsor or a product owner followed by what capability we r expecting to deliver or build as an acceptance criteria

    Sometimes even the right stakeholder needs some guidance(whys to invoke their thoughts) to help them articulate) the benefits or capability they want to achieve and cross business impact analysis is what we as bas help them to take into consideration, the journey is sometimes bumpy but have always proved worthwhile to get the expected outcomes in getting the complete picture

  • Declan Chellar

    Hello, Bharathi.

    Thanks for taking the time to read and comment.

    I agree with your second paragraph but not your first. Stories should be explored with the stakeholders who are going to derive the business benefit expressed in the “so as to” clause. In my experience, that is usually not the project sponsor or the product owner. The product owner’s job is primarily to prioritise the backlog.

    The point of my post is that those stakeholders are often not “users”.

    Kind regards.

    Declan

  • Kinjal Sengupta

    Hi Declan,

    I couldn’t agree more to your point. I found similar constraints while dealing with stories where the actor is a system. The narrative sounds to weird when you say, “As the rules engine system, I need to automatically run so-and-so Agent, so that so-and-so data get updated, and so-and-so emails are sent to so-and-so party.” It’s like trying to force fit a structure just for the sake of it.

    Regards
    Kinjal

    • Declan Chellar

      Thanks for reading and commenting, Kinjal.

      I have also seen user stories where a software system is the actor, instead of identifying who the human actor is who derives the business value from the capability described in the narrative.

      Kind regards.

      Declan

Leave a Reply to Declan Chellar Cancel reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>