Magical User Stories

Agile ways are great. They are an enormous improvement to the old ways. However, that doesn’t make them “complete” or infallible. We should always be striving for better ways of working. One thing that has always bothered me is the “Magical User Story”.

You see, most descriptions of agile methods assume the customer knows what she’s doing and that she can, with some help from the “tech guys” maybe, create a prioritised list of her needs. Popular methods like XP and Scrum have very little to say about how the user stories are born. They’re just there.

This is nonsense, of course. User stories don’t magically appear out of thin air and dive into the product backlog, giggling with anticipation.

But wait a minute, I can hear some of you say, we have a role for that. True. There is this role in charge of the story thingies called the Customer or Product Owner. But does having a role really guarantee the effect we’re after? “- Right, Sir! You’re in charge. That’s settled then. Jolly good, there it is.” No. It doesn’t work that way. Just making someone responsible doesn’t mean we’ve got it covered.

The responsibilities and methods of a Customer/Product owner are described in a rather shallow way in agile methods, because the people who designed XP and Scrum et al were developers. They didn’t know exactly how that work could be performed in a professional way.

I am not saying that Customers/Product owners are incompetent – I am saying that the work they face with is hard, really hard. Most people believe that the Customer/Product owner should be just one person. Then, apparently, we won’t get that conflict of interest that having several customers normally generates. (Yes, we will, only it’s shielded from the developers.) But what if the work is simply too difficult to handle for one person?

I think that the role of the Product owner as one person is naive in all but the trivial cases. This is partly for practical timing reasons, how could one person stretch all the way from having intimate contact with the market, over using political clout in the organisation to get things done, to helping define and validate examples of how the system should work with the developers? Sounds massive, right? It is. Maybe they have a black hole in their pocket, because I can’t see how one person could handle that without some kind of time-control device. But most of all it is because that task is simply too difficult and important for one person to handle.

What is that task? Well, the main task of the customer/PO is to guide the product development in maximising its return on investment. In other words, they must decide what should be built. They must know the value of things. Now it gets difficult, how can they know this?

If I were to ask myself, an agile advocate, this question, I would answer: Release early, get feedback, refine and repeat the process. But that’s only a partial answer. Do we really have to settle for having to deliver some crap before we can start improving it? I am certain we can do better than that.

To be sure, iterating towards a better solution will slowly result in a better product but progress will be slow. Why is this? Because there is nothing in agile methods that make us connect on a deep level with our market – get inside our users’ heads. There is nothing on how we should select our business goals and steer towards them. There is nothing about measuring how well we succeed.

Just iterating won’t be enough. We need more skills. We need many perspectives for this task to do a good job: business process knowledge, technology skills, marketing and sales experience, and domain expertise. But most of all, I believe we need to connect better with our users.

Users are surely our most underestimated resource. As it has been said before, there is only one other business that calls its customers “users”… I think this rather well reflects what we think of them. And yet, they are the ones who know how to do the work, with or without our systems and products. They are the people who demand service and buy our stuff. Maybe we should start talking to them?

6 thoughts on “Magical User Stories

  1. Exactly! That is why I advise product owners to get started with effect maps. Creating an effect map will force you to think about users and prioritize usage scenarios based on how users will use the application. This, in turn, will help you decide what goes on the backlog and in which order. You could call this “strategic usability” to separate it from “the button goes here” usability.

    Scrum has not helped product owners a bit. It has just drawn a clear line of responsibility in this area. In my experience this leads to efficient teams driving in no particular direction at all (just a lot faster than before).

  2. Feedback between iterations tend to give you feedback on the question: “Are we doing this thing right?”

    The most valuable feedback would be answering this question instead: “Are we doing the right thing?”. That question is much harder to answer, as you pointed out….


  3. Pingback: What’s Missing from Agile? « Den bloggande terriern

  4. Pingback: The Design Flaw of Agile Methods « Den bloggande terriern

Comments are closed.