User Stories during project planning and development

Getting a project off the ground and underway can be a daunting task, especially for larger and more complex builds. For sites that are particularly content-heavy, the initial considerations required before beginning development are extremely important.

I like to make use of a concept known as "user stories" when starting a project. Basically, this process takes the form of writing, or sketching out – in collaboration with the client – the goals of the project and what needs to be delivered in the finished product.

User stories are part of the agile approach to programming, a process which allows the planning and decision making phase of a project to proceed smoothly and, importantly, with the involvement of everyone.

You may already have experience with user stories. The following is only an outline of the concept, and doesn’t delve into some of the more detailed analysis of the process. However, I find that the basic principles involved are very useful when it comes to planning and executing an efficient project.

A story is very simple – by design. They are usually structured as follows:

# As *a type of user* I can *do something* to *achieve some goal*

Although the specific structure may vary, depending on preference. The purpose of that structure being to force your thought process down a specific path. Specifically, the path that your users would take when thinking about what they’d want from that specific feature.

As a rough guide, the user story should be short enough to fit onto a 3′ x 5′ index card when written with a narrow marker. This sounds somewhat arbitrary, but it serves as a good indication for whether or not a given story contains too much detail and needs broken down into smaller stories.

Also, writing these stories onto index cards is how a lot of teams located within the same physical office may implement this process. It’s a good, hands-on approach which encourages interaction.

The "who", the "what" and the "why"

It’s vital during the planning process to determine not only what features will be needed, but also why they’re needed, and who is going to be using them. After all, the target audience for a given app or website isn’t the client, it’s the clients users/staff/customers/visitors…. It’s not something that always comes naturally to people, and laying out stories in this way helps to channel your thought process.

So, a "real-world" example might be:

# As *an editor*, I can *add new articles with text and title*
# so that *I can ensure site visitors see fresh content*

The last part, the goal, may seem redundant. But if anything, it’s the most important part. This is where your users intentions are recorded.

Imagine if, as a developer, you were to recieve a list of user stories from a client, or another department. You have no way of knowing how the customers think. After all, you’re a developer. You don’t work in the same environment as your client’s customers. You probably only know the bare minimum about their business sector – that is, until you read through the user stories. You not only have a description of a required feature, you have a specific why behind that feature. Through the user stories you gain insights into the user’s perspective.

The ‘why‘ might be obvious, it might not be. But what’s important is that it’s there.

The story can encompass as wide a range of features as required. In fact, it’s usually better to "think big" to start with. "Adding an article" is a fairly high-level function. In reality, from a developer’s point of view, it requires many more smaller tasks to be completed to get this high-level task working.

But that’s part of the process. The developer then takes the "high-level" user story and breaks it down into multiple smaller stories. These start to form the basis of the full project specification which, once complete, can be delivered to the client as a full and extremely thorough outline of all the requirements.

The discussion

Another important purpose behind user stories is that they foster discussion. Without user stories, it can be hard to determine what needs to be discussed in order to properly plan out a project.

By defining features in this way, as well as defining why they need to exist, you’re actively encouraging discussion and input from everyone involved in a project, be it the developer, the client, the client’s staff or the client’s customers.

User stories invite everyone who will be involved in the project from the start and throughout its lifetime to contribute. There should be sufficiently complex discussion about each point to fully appreciate what needs to be built from a user’s perspective.

The discussion is perhaps the most important part of the whole process.

Acceptance criteria

As well as the story and the discussions, an important third element of the user stories is the acceptance criteria. This takes the form of a short list of desired functional outcomes which should be brief enough to write onto the back of a post-it note or index card using a standard ballpoint pen. (again, this is purely to give guidance as to the expected length of this list. Too long, and it becomes unmanageable. Too short, and it may not be sufficiently detailed)

For example, in the above example our completion criteria might be:

# The title box accepts between 1 and 100 characters
# The text box accepts any number of characters
# A save button is visible to publish the article
# An error message will show if either the title or the text is left empty

This is a fairly simple example, but you can see here how this defines the expected behaviour of our feature. This also allows us to define when it is complete.

By noting down the acceptance criteria, we have a 100% agreed upon definition of completeness. This can be used by the developer to build the feature, QA to test the feature and the client to sign off on the feature.

And there will be no disagreements on whether or not a task has been done. If it meets the acceptance criteria, then it’s done!

After the stories are told…

At first glance, this might seem like overkill. I’ve recieved comments before questioning this approach, and wondering why so much work is required at the beginning of a project, but if anything, it reduces the amount of work. For each hour at the start of a project I spend on user stories, this can easily save two hours of frustrating debugging and modification at the end of a project.

Now, once the project is underway, this is where the value of the process becomes apparent:

• During the development, I, the developer, make use of the user stories to build the functionality
• I can also make use of the user stories to develop "automated tests" – very clever, code-based tests which can be run to ensure that "Yes, this functionality achieves X when presented with input Y" (to simplify the concept)
• You, as the client, have a thorough and detailed document to refer to throughout the build to make sure that everything’s being built to plan. This saves having to jump between notes and email chains to figure out if we planned on building X, Y or Z
• Additionally, the structure of the document reads in a logical fashion, meaning you can easily find specific notes on specific pieces of functionality
• This process makes it simpler to add new stories throughout the project, if extra functionality is deemed necessary. Because the list of stories is well defined from the start, new stories can easily be budgeted and allocated time & resources, if available (User stories make it easier to determine if new features are feasible)
• After the project is complete, the user stories act as a "Signing off" list, allowing you to check through all the required functionality, and ensuring that it meets the specification (This can often be a messy part of a project, and the final stages can sometimes be drawn out much longer than necessary if a detailed and clear list of requirements isn’t available)

So when considered as part of a full project lifecycle, I find user stories to be an invaluable and effective tool in properly planning and scoping out a client’s requirements.