User Stories for Understanding Project Requirements
Something we have started doing very deliberately, something that really works to help us accurately scope and manage a project, is writing user stories for understanding project requirements. It’s not a new idea by any means, and we’ve always thought this way, but we’re seeing now it as a “must-do” step in our process. When we’re trying to get our arms around a project, it’s a formula to get moving with.
What’s in a user story? It’s simple (at least the way we write them). It’s just one thing a user can do and why. That’s all. So it describes an action the user takes…and thus implies a function we need to enable, and a user experience we need to streamline. You put all your single user stories together and voila: that’s the entire website project in action form. It’s also a great way to start documenting your work (more on this another day).
A user story has a beginning, middle, and end. First is the Who. In the middle is the What. Last is the Why.
It looks like this:
As a <type of user>, I can <do something> so that <some reason>.
or
As a <who>, I can <what>, so that <why>.
The Who is important because it differentiates between types of users, whether they are:
- “anonymous” (non-logged in users, more than likely existing/potential customers who only are allowed to view specified pages on your site).
- “authenticated” (logged in users with more permissions than anonymous types…in addition to being able to view content perhaps they can also upload attachments, write comments, or otherwise interact in some way).
- “administrator” (can do just about anything from creating/editing content to SEO customization to menu manipulation, and lots more).
- there are other flavors of user types and some hybrids, but these three are pretty much the arch-types.
Here are some examples around posting comments on a blog:
As an anonymous user, I can read all recent blog articles in ascending chronological order, so that I can learn about what X company has been up to most recently.
As an authenticated user, I can submit a comment to a blog article, so that I can provide feedback to X company.
As an admin, I can moderate and approve/disapprove of comments submitted to my blog, so that I can ensure that my blog comments are not inappropriate or offensive.
Three different angles for three different types of users, all concerning the same aspect of the site (blog comments), but now we have defined the workflow and we can start discussing it in more granular detail. For the authenticated user, we can extrapolate to think “hey, we will need a little message that says ‘thank you for submitting, awaiting moderation now’”. For the admin, we need to start knowing how he will be notified that there are comments awaiting approval, or is he allowed to edit or just approve/deny. It appears to build on itself…but really these project requirements were lurking underneath the surface since the beginning. We’re simply seeing the whole iceberg better.
As you can surmise, one of the big benefits of writing these silly user stories is that they often foment discussion and further investigation. That’s a wonderful thing…the devil is in the details. When we get to a point where we have written every last possible user story we can possibly know about…that’s when we can put an hours estimate on implementing each story to completion and feel confident that we’re not missing something. Our clients and ourselves can talk about the project in a very informed fashion. The formulaic writing process forces both parties to suss out the hidden complexities of a project, and evaluate these for priority, i.e.maybe there’s a more efficient way to approach the What, so you can still provide the Why that matters to the Who.
Tags: agile, requirements gathering, user stories
