Bring your stakeholders together for a story mapping workshop

Recently, I participated in an agile business requirements training given by my colleague Thomas De Vries and Patrick Steyaert. One very interesting technique that they highlighted is story mapping. In this post, I will explain how to apply this technique and highlight the advantages compared to traditional techniques for eliciting requirements.

4 Tips for writing business user stories

Business and IT speak a different language. This is a challenge for many organizations as it hinders communication about requirements in IT projects. An often suggested way to deal with this problem is to use the simple and fixed format of user stories to express requirements (as a..., I can... so that ...) and I fully agree on this. However, as a business analyst, I notice a lot of confusion among business people when it comes to the definition of a user story. I often hear that user stories are too technical for them. In this blog post I provide 4 tips to write user stories that express business requirements making sense from a business point of view.

The beer coaster analysis

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?

Please stop writing 200 page documents

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.)

Requirements are dead

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.