How to Use User Stories to Build Your Website

In Agile software development, a user story is defined as one or more sentences to capture what a user does or needs to do as part of his or her job function. It is written from the perspective of a user and captures the who, what and why of a requirement in a simple, concise way.

Here is a simple formula for writing user stories:

As a [user role], I want [a feature or goal] so that [a benefit or reason].

Here are a few examples:

• As a customer, I would like a one-click purchase option so that I can save time when buying online.
• As an editor, I would like to review content before it is published so that I can assure it is optimized with correct grammar and tone.
• As a customer, I would like to be able to flag content so that I can find it more easily in the future.
• As an activist, I would like a community so that I can share ideas and collaborate with like minds.

One thing you might notice from this list is that each of these stories will vary in length depending on the user’s requirements. While flagging content is a simple feature to enable in Drupal, building a community can be a huge task.  Therefore, it is to be expected that these stories are of varying sizes. The most important thing is that they have been captured and now can be prioritized.

You might also notice that there is not a great deal of detail. An editor is asking for a publishing workflow. What will that look like? Will it have multiple states such as a draft, legal review, brand review, etc.? Will editors get emailed when they need to review content?

User stories are like high level requirements in a waterfall process. They don’t need details right now. Details are added in the design phase. In Waterfall, all the design is completed up front before coding begins. In Agile, design is discussed every few weeks and story details are fleshed out just before beginning work on the user story.

As you see your site coming together, you will have a better idea of how to build it. User stories are iterated on and improved upon as we learn more about what we are building. Some user stories may ultimately look nothing like what you thought at the beginning of the project simply because you and the team came up with better ideas or found a more efficient way to build it. There will even be some user stories that you won’t use at all, so don’t waste time sweating the details in initial planning.

We like to think of user stories as documented needs and reminders for the stakeholders and development team to discuss later.

Need a simple way to prioritize your user stories? Try the MoSCoW approach. MoSCoW is an acronym that stands for:

• Must haves – we need these stories in order to launch the project.
• Should haves – these are of high importance, but are not show-stoppers for the next release.
• Could haves – If we get a couple of these in it would be nice, but they can easily be moved to the next release.
• Wants – These are not a priority but we want to keep track of them as possibilities for future releases. 

If you aren’t used to commissioning websites or applications, user stories are a great way to communicate your requirements.

Photo courtesy of Juhan.