AE Stories

It’s Monday morning and the daily scrum just took place. An analyst got the task to dig into a problem. He eagerly starts working on it at his desk, digging deep into the issue trying to make it crystal clear. Doing everything he can; creating diagrams, modeling, drawing, … Putting in time and effort. The analyst goes to the developer’s desk to discuss the fruits of his labor. While going through the entire stack of documents, he figures out that all he needed were some quick sketches on a the back of beer coaster. So where did he go wrong?

Despite agile and lean being more popular than ever, 200 page analysis documents are still very much a reality. There are many reasons why you shouldn’t write this type of documentation but if I would have to choose one major reason it is that nobody actually likes to read these documents. Here are some other good reasons not to.

Inconsistencies

It is hard for anyone to remain consistent throughout a long plain text. Inconsistencies already start creeping in while you’re working on the first version. Then updates are made by you or even more risky, by other people. (If you don’t believe me, just take a look at all the inconsistencies in the Harry Potter series.)

In response to my previous blog someone drew my attention to an article published a year ago by Ron Tolido: “De Dood van Requirements” (the death of requirements). The author foresees a brighter future if we stop thinking in terms of requirements, a future where ict and business collaborate in such a way that there is no longer a need to specify requirements.

It is a compelling vision. Traditionally, requirement elicitation and management consumed an inordinate amount of time and effort. So instead of just trying to speed things up, elimination seems a valid cure.

Ever since user stories were introduced to the world they have been compared to use cases. There has been a small war between the agilists promoting user stories and the “mainstream analysts” holding on to their use cases. But is all this rivalry really necessary?

When comparing use cases and user stories, they turn out to be different in every way:

• Use cases can be used as permanent documentation, User stories are thrown away at the end of the iteration
• Use cases are at the level of what the user is trying to achieve with the system, User stories are small enough to plan into an iteration and to iteratively and incrementally deliver value
• Use cases are a base for high level preliminary estimations, User stories are a base for development estimates

So to me they simply serve different purposes

 

In every requirements management effort there is a moment when the seemingly inevitable question comes up: “Are we talking about business requirements or IT requirements”. Other taxonomies are in use - the BABOK lists 5 levels- , this specific question seems to be triggered by whom should own and validate which requirements.

I will not discuss the role issue but I will demonstrate a clear distinction between business requirements and IT requirements. The answer boils down to dependencies.