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 focused 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 focused 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.
Does focusing 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?
Declan Chellar
