User stories

Methodologies. Agile. Scrum. Extreme programming. Lot of methodologies. « User stories » is currently very fashionnable. That’s Ok.

When I was a developer, I did not think about methodologies. You are a good developer or you are not. And if you are not, there is no methodology that would change that.


One day, a project leader explained me that I had to write specifications for the user requirements, before to start programming. Why should I have to waste 2 or 3 days writing specifications and wait a week for I don’t know who’s validation when I could have the job done immediately?

All right, I can understand. Too many times I did start to hit my keyboard before even thinking and at the end of the day, I had too many lines of code that even I could not understand and worse, that did not do anything. Bugs, bugs, bugs. So I learned to take at least 10 mnn to think, draw a sketch, even think an algorithm.

This was a time when methodology meant designing an algorithm. After that, it was entities and relationships. Structure the data as entities and define the relationships between them. A french methodology called Merise, very famous in the 80’s. At least I liked it, because it was like a game and it was really helpful to design the data layer.

The only problem is that you begin to have a lot of meetings and please, take a lot of paper because we will spend some hours talking about if this relationship is bi-directional or not. And you know that the more people around the table and the more talking. Let me tell you what I think: if you are on « user stories », and even if you just have only 2 people around the table, if one is a developper and the other one is an user, I woud suggest to forget the methodology for some simple rules.

Developers are from Mars and users from Venus

Developers and users do not talk the same language, so why waste time on « stories » ?

The project is late. The project leader has a meeting on the morning with users who tell « stories ». And then he works on his spreadsheet to re-schedule the planning. And then has another meeting to sell the new schedule to the users. And then a meeting with his boss to talk about the final schedule. Which leads to more pressure. And then he comes to the developer who stops everything he was doing and rapidly develops some prototype so that there is something to show during the next meeting so that the users can see that the whole team did start working on their « stories ». Maybe the users – or his boss – will be happy. More frequently, the users will tell another « story ». Or that the project leader did understand anything because he his an idiot.

The only methodology I know is « garbage in, garbage out ». As a project leader, my first priority has always been to make it clear that I would not be responsible of the garbage in. So :

  1. The developer does not start anything before the user has a « story ».
  2. The user writes his « story » and the user signs his « story ». With his own blood if possible.

Everything is critical

Users want all and everything. I once had a meeting with around 20 salespersons to list their requirements. After a couple of productive hours, we had written all what they did expect for their sales application and I asked them to define what was critical, what was important and what was only nice to have. They looked at me as if I was asking for a bargain, and they said « everything is critical ». So I explained:

« A customer is calling you on the phone and you want to get his records, sales orders, contractual data and personal information, even to know his hobbies, and you want it in 1 second on your screen, right? And you want to be able to update this information as quickly as possible while he is on the phone? »

« Yes. The customer does not wait. »

« You also want to be able do all possible kind of queries on all possible data to identify specific sets of customers to target and generate mailings to send them, right? »

« Yes. »

« Well, you can get all the data of 1 customer in 1 second, or you can get 1 data for all your customers in a pretty short time, but you cannot have all the data of all the customers in 1 second. »

I explained that to get one kind of information as most quickly as possible, developers use indexes on the information, but the more indexes you use and the slower the whole system. I believed that the query to get one customer’s records was critical, so I engaged myself to provide them this functionality with the expected response time. Then, I told them that, even if the ability to do all kind of complex queries was important, this was not something they would do every day but rather once in a month or two. And if it was slow, well, once in a month they could take a coffee while waiting for the results. And they did agree.

Salespeople may be tough but at least, they understand the concept of negotiation.

So, whatever « stories » the users tell you, the important is that:

3. The user defines priorities.
4. Deliver the critical, do as best as you can on the important, the « nice to have » if for the next version.

I want the moon

Another project was to develop a web site for gardening. That was a difficult project with a too much tight schedule, not enough people in the team, and a lot of pressure. And the users did not know what they wanted and their requirements were changing constantly. Until a day when the VP in charge of the site asked for a section about « the moon and its influence on plants ».

I thought it was completely irresponsible to ask for such things when we had a lot of more important tasks, but as he was the big boss and most important « user », I could not refuse. I asked the younger developer in the team to do a quick prototype, and not to waste to much time on it. He rapidly designed a section with 2 or 3 pages that the user could update, change the text, put some links, etc. And he placed a moon at the top of the pages.

I presented it to the big boss and his assistants, on my own screen, and even if it was not everything he did ask, he liked it. But then, he just did something stupid: he indicated the upper right corner of the screen and said « I want the moon here ». I called the programmer who was at the far end of the room and everybody could see, while he slowly came to my desk, that he was weary of another user’s caprice.

The big boss reiterated his demand: « Is it possible to have the moon here? »

The young guy looked carefully at the indicated location on the screen and just said « No ». Then he went back to his place, quietly walking through the whole astounded room. The big boss was so surprised that he just looked at the screen and said « Well, I suppose this is pretty well as it is. »

After that, we did not have any more problem. No more changing requirements. I sometimes invited the young programmer to project’s meetings with the steering committee, and he sat at my right with his weary face and saying nothing, so that everybody remember that « it is pretty well as it is». I called him my “Kill Bill”.

The lesson here is: everything that the user requires is not really the best for the project. The problem is not to understand the user « stories » but to produce an application that fulfill at best what is needed for the business. The developer can change the stories until the user proves it is really necessary.


I have a lot of stories about users as you probably have also. Whichever methodology you use, they are some basic fundamental “keep it simple” principles to remember.

The job of a developer is to make the application working, with development tools that are bugged, with database whose response time is not predictable, with bugged libraries, not to talk about language mysteries, best practices, etc. And they are even facing more problems because everybody is going into the cloud so they don’t even control any machine to work with. Oh, sorry, there was saturation on the virtual machine so you have to wait for your build.

Developers have already enough problems without asking them to understand « stories ».

Leave a Reply

Your email address will not be published. Required fields are marked *