/Logos/ae-logo-pos-rgb.svg){kind=logo}
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.
Tip 1: Be sure where you want to arrive before you start going
Before diving into writing user stories, clearly define the high-level customer needs that you want to address. This sounds logical but I see a lot of projects with objectives being too vague. So only when you have defined the goals the project will contribute to, it is time to start writing user stories that can be linked to these project goals.
Tip 2: Consider the subject of a user story as a task after which you can drink a cup of coffee
You should never be asked to limit user stories to a size no larger than a couple of man days of development work. User stories written to facilitate discussions with business people should deal with concepts relevant to them. A core principle to bear in mind is that a user story should express a business task after which the actor can take a break: "As a car salesman, I can plan a test drive for my customer, so that he can decide whether he wants to buy a specific car".
Tip 3: Separate implementation ideas from business user stories
The user story format is often used to express IT requirements rather than business requirements. An example of a user story that does not meet the criteria stated in the second tip of this blog post is the following: "As a user, I can sort cars by model, so that I can easily find back a car for which I need to plan a test drive". Sorting cars by model does not make sense from a business point of view and it cannot be considered as a business task that adds value.
However, this 'wrong' user story expresses one of the possible means allowing a car salesman to plan a test drive for his customer. If such an implementation idea (which can be considered as an IT requirement) pops up during the writing of business user stories, I suggest to capture it as a solution suggestion linked to the user story that expresses the underlying business task. I recommend anyone interested in the difference between business requirements and IT requirements to read this very interesting blogpost written by my colleague Robrecht David.
Tip 4: Never eliminate the "so that" part of a user story
For two reasons, it is extremely important for a business analyst to capture why a user wants to perform a certain task. Firstly, it provides crucial context to understand the requirement, assuring that the requirement is not ignored by team members. Secondly, if the goals stated in the ‘so that’ part of the user story cannot be linked to the goals the project is seeking to achieve, you should ask the question whether the requirement is valid.
Applying these 4 tips should allow you to express business requirements as user stories, which is a format very concise yet meaningful for business people!
Interested in writing your business requirements as user stories or discussing this blog post? Leave your comment below!
