Archive for 2009/06/16

The difference between knowledge and understanding

We can all hope this is true…

(From Indexed)

Categories: Agile Tags:

Why user stories are not silly

I’m currently reading The Goal, an experience not unlike reading Godel, Escher, Bach in my youth or Sophie’s world a couple of years ago. Using the novel form to explain Business improvement (The Goal), Mathematics (GEB) or philosophy (Sophie’s world) seem like something impossible, but in these three cases the form (which, I grant, is only partly used in GEB) is truly successful. The reason is that the story format probably works well with human brains. It’s like it’s described in Made to Stick; by presenting a story, the information sticks better in our brain.

And yet, it doesn’t seem natural to even consider writing something so important in the novel form. It’s almost like if a subject is grave or important, the presentation should “fit” that. Perhaps this is also the reason for why so many question the user story format. Just the name is probably a hindrance.  Are we going to write “STORIES”. Are you going to gather all developers in a room and write stories. I guess the postits add to the kindergarten feeling most perhaps feel when presented with the user story idea in the first place. I mean, we need the developers to work (AKA, create code).

But stop and think. Like the main character in The Goal does. What’s the goal?

Well, the goal of every IT department should be the same as the rest of the company. And all companies must make money. Perhaps not today or tomorrow, but if you don’t make money, you will never survive.

OK. If the goal is to make money, what do you do next? Well, you should start moving in the direction of making that money. That does not mean that you should only focus on the things that bring in money now. That can, as you probably know, even make you lose money in the long run. Taking on customers who you can’t handle can cost you in the long run. Skipping that training for the developers can make them make simple mistakes. Etc. What is important is not taking the steps in the directions that doesn’t make you earn more money. OK, a company can of course participate in altruistic programs for help organizations, but this is just an exception. When you are at work your tasks should lead to your company making money.

But now the old lady has gone bananas. Starting with some strange books, moving over to user stories and now she’s rambling about making money. Where’s she going with all this?

If we now take that notion of making money down into the deepest corners of the developer’s department and sit down with Greg, the geekiest guy on the block. And we sit there and ask him – How will that piece of code make us make more money? What are the chances that he has no idea or worse; a false image? But why? Because some consider developers just working when they crunch code. That is what makes the company making money. If a developer is not crunching code, he’s not productive.

But what is a productive developer. Well that should be something like this:


Yes, there could also be something that could be disabled and then the two end boxes switch places, but the principle is the same. Now consider these two scenarios.

A: A user wants to do X in system Y and a change request is formed by him and the tasks are handed to a developer, who develops the functionality and delivers to the user.

B: A user wants to do X and discusses this with a developer. The developer informs the user that this functionality is already built into system Z and the user starts using that instead.

So, how was the productivity of the developer in these two scenarios?

How common do you think that this is. Or the scenarios where stuff is built more complicated than needed, or wrongly because something was misunderstood? Or the thousand other cases when the developer simply didn’t know what the user wanted and the user didn’t know his options. When presented with options (not too many but a handful) an intelligent user can often realize that he himself didn’t know what he wanted either.

So, how can we best inject the knowledge into the developer? Well, giving him that specification is a clear path to failure. And in the case of our two scenarios, the specification in itself was waste since it was never needed in the first place.

What we need are more stories. So, is it enough just to use the user story format and give the developers that bunch of story cards?

Have you seen the Dead Parrot sketch by Monty Python? When the sketch was first presented to BBC, they simply wrote down the dialog but no one could see the joke (well, perhaps you don’t like Monty and then it’s never funny) and it wasn’t until they played the stuff the greatness was spotted. And it’s the same with user stories. The actual text is just a reminder, it’s the forming of the story which brings value. Remember that the objective is making money and if we can do that without writing any code at all, we can spend that time on something else. But to enable this, we must use the competence of the developers and the business people at its maximum. And user story workshops are an excellent tool.