What is a user story?
Stemming from agile software development, user stories are used by the customer to concisely convey what they need in their site or software. In only a sentence or two in the language of the everyday user, a user story describes a solution requirement. While they can be a by product of in-depth requirements gathering process, their use can replace extensive documents on smaller projects.
No really, what is a user story exactly?
While there has been some discussion of how user stories should be structured, we here at Pop Art derived a pattern similar to this one that states:
To <achieve some value>
As a <role>
I want <some feature>.
In this version the value of the story is placed first, and yields a bit more importance than the role or the feature. The object of a user story is to state in simple terms specifically what the product needs to provide, without branching out into how it should be designed, what the user interface should look like or in what language it should be developed.
Recently we wanted to better streamline our QA process here at Pop Art and create a piece of software that would better help us list and track the completion of all the needed tasks to assure we deliver a high quality solution. Some of the user stories written for the development were:
- To avoid overlooking common but important tasks on large projects, as an employee, I want a centralized checklist of our collective knowledge.
- To identify the amount of remaining checklist items for a given project, as an employee, I want a view of the entire project checklist display the status of each checklist item.
- To improve the value of the checklist items over time, as an employee, I want to insert, update or delete checklist items at any time.
These user stories don’t describe how the user clicks here, or on which area of the site they do what. From this document it is actually difficult to tell that the solution is to be a piece of software. The focus is placed on the value needed and the business tasks that need to be achieved.
How are user stories used?
When I worked off-site on a large software project that spanned several months, user stories were written on small 3×5 cards. I suspect the process of arriving at these small nuggets of information was tedious. It took several stakeholders, pouring over gathered requirements from all of the various areas this product would touch – business/marketing, legal – and the various types of end users.
From large amounts of data, they were able to work with a developer/project manager to determine which user stories would be worked in which order throughout this large agile project. Once priority and time-line was established, each user story was then broken out into a series of tasks for various areas, like design, programming, and front-end development. Each of these tasks would span a short two-week period or a “sprint”. This allowed each of us to focus on what we were to accomplish without losing the larger focus of our overall goal. At the end of two weeks, the stakeholders would then test and view pieces of the software assuring that the requirements for that particular story had been met.
What can user stories do for me?
Be it on large or small projects, user stories are used to slice requirements into manageable sections and pieces that can be digested and completed in a quick manner. They are often coupled with a way for the customer to test and validate that the user story requirement has been completed successfully. The key behind this kind of development process is a strong interaction between the stakeholders and the project team. In this way a project can be jump-started and the conversation begun around what the perceived function and value a system or site should embody. Often user stories go through quite a few iterations which communicates a lot of information in a short time, making development time and cost estimation more effective.
