In the last few days I’ve been reminded of the importance of writing user stories for requirements, and more importantly, on teaching our clients of their importance.
In November of last year, the client started creating a list of requirements on a spreadsheet. Since they are not completely trained in Agile, the list of requirements was what you would expect: short phrases trying to explain each requirement. When we first went over these, I didn’t see anything wrong with them, I even thought they were pretty clear since we had discussed most of the requirements at least once before.
It was only when we met again this year to discuss the effort and priority for each of these requirements that my boss made us realize they weren’t entirely clear. They were missing an essential part of all requirements: the WHY, the purpose of the requirement.
When thinking about a requirement, it is very easy to make the mistake of only thinking about how it should work and for whom, but we tend to forget about explaining the why.
The why is essential. Without it, the requirement won’t be fulfilled. Take this client requirement as an example:
“Freeze headers on all pages”
With this, I knew that we would need to freeze the headers on all pages for all users, but since I didn’t know the why, I didn’t understand what exactly they were expecting.
My first assumption was to freeze the top bar, where the logout link is. But after digging a little further I realized that was not the case at all. What they wanted was a way to quickly know what page they were on without having to scroll back up, so my assumption was oh so very wrong.
Now, if that had been a user story, things would have been clearer from the beginning. Let’s review the previous example – but this time as a user story:
“As a user in the system, I want to be able to see the title of the page I’m on, so I can easily identify where I am without having to scroll all the way back up.”
With a user story, I get context. I understand the reason behind the requirement – without my personal assumptions. This doesn’t mean we need to ask the client to write the user stories, but we do need to teach them the importance of having requirements framed as user stories, even if we are the ones writing them.