•
Share

User Stories – less writing, more designing

Posted on by

Anyone who has ever done a project with more than three or four people is familiar with the dilemma: either you spend a lot of time to write things down or misunderstandings arise frequently that will cost time and nerves.

And that planning is what distinguishes successful from failed projects, has meanwhile spread.

Every web and software project creates countless documents: quotations, cost estimates, specifications, job descriptions, rough concepts, detailed concepts, design concepts, scribbles, wireframes, prototypes, presentations, test plans, test reports, Reviews – and of course a number of presentations and lots of e-mails.

The UX expert Jeff Gothelf even goes so far as to say that we are in document-driven business (“deliverables business”). And in fact, we are still regarded by many customers, bosses and colleagues for what we deliver: convincing documents, successful presentations, proper documentation.

That means, we are all much too focused on the means to an end. Nothing else are all of these documents. If there is a successful product at the end, no one is interested in the entire documents anymore, for which we have spent so much time.

So one of the key demands of agile development for some might be tempting:

Working software comes before documentation.

And yet: Many don’t feel very probably: For one, you ask yourself: How to make the project to a success if you quit all these documents? And how can customers, bosses and colleagues see that we make a valuable contribution to the project, if we don’t document everything?The path to a successful product also don’t cope without documents with an agile development. But there are fewer documents and above all, they are shorter – and easier to use.I think this alone is a sufficient reason why we should deal with this way of working as a UX expert.

Symbolische Papierstapel

Functional specifications – the classic way

The term Functional Specification sounds as bulky as dusty. Even in English, he is not better. Often there is also a Software requirements specification, the requirements specification – in short Requirements.

On the difference between these documents I will not take up here – because today as a non-programmer you only have rarely to do with functional specifications & Co. For many years they were the standard for large software projects, there is even an ANSI standard for that.

All these documents tried what is believed to be impossible now: at the beginning of a project everything should be set so clear that all functions can be on time implemented in the required quality and with the planned effort. Functional specifications try to fully describe the proposed system.

Use Cases – the user comes into play

As a UX expert you already feel much more comfortable with the use cases or user scenarios.

They describe what the user will actually do with the system what has to be created and how this reacts. A single use case defines what happened between user and system when he tries to do his job with the system.

UML-Anwendungsfalldiagramm

The task should be fully described, with all the necessary steps.

The most common pattern is the one of Alistair Cockburn and contains 13 points, among others: name and shorthand symbol, brief description, actors involved, triggers, preconditions and basic flow.

An example of the short description of a use case (ie only one of the 13 points):

The customer always wants to be able to see the status of his booking, to change the data and details,  to cancel the booking or to contact. The system informs him of the success of its actions by text outputs as well as by e-mail.

In order that it is not too complex, each use case must pass the coffee breaks test: If the user would take a coffee break during the described object, the task is too complex. You should then break it down into several sub-tasks.

User Stories – now it is getting human

Working with User Stories (user stories) is the youngest of the methods presented in this paper to describe a system that will be implemented. A user story is also the smallest element: it describes the smallest possible task that can the user do with the system.

 

It is formulated in everyday language and kept as short as possible.


An example would be a user story:

As a business traveler I would like an overview of my current hotel reservations, so that I can cancel one of them.

A user story usually include not only such a description, also a title as well as the acceptance criteria. Acceptance criteria define when the requirement is met. These criteria are usually the instructions for testing – if the acceptance criteria are checked and the system meets these, the user story is considered to be processed.


There are usually 3 to 4 criteria that must be met. If there are more than 10, the user story itself is probably not well defined – and you should break it down into more than one.


It has proven its worth to write down user stories on index cards (A6). In this way the amount of text is limited. Title and description are placed on the front page, the acceptance criteria on the back.

Fits the user story is not on the map, it is not fragmented enough.

Many stories tell about the product

What the future product is able to do is described by the user story that is defined for it. However:

A user story is not a specification.

And the totality of all user stories should not replace traditional specification.

Because user stories are mainly used in Agile development. This should(more simplistic) further software projects faster and achieve a higher quality than by conventional methods. The core point here is to work in small steps and frequent iterations.

In the Agile development one thing is central: The conversation.  Means that nobody here works for weeks quietly at his desk to present something afterwards. You meet regularly and in short intervals to discuss the situation and how to proceed. Testing is part of its everyday life.

User stories are therefore more an invitation to an interview as a stand-alone document. A good user story stimulates discussion and reminds the participants in the conversation about what they have discussed.

Better overview: User Story Mapping

To retain the overview of complex tasks, I like the technique of mapping user story very much.

Jeff Patton, who made known this technique, describes it like this:

In the team I tell the history of the product and write down every major step of the user on a post-it. Afterwards I order these post-its from left to right. Then we go back and talk about the details. Each detail is on another piece of paper and I will arrange one after another under each step. This creates a grid that tells the story from right to left – and each contributes the details from top to bottom.

Abbildung aus Buch User Story Mapping

If you are interested in this technique, I recommend you the book by Jeff Patton warmly: User Story Mapping: Discover the Whole Story, Build the Right Product.There he describes very entertaining and in an easily understandable English on 322 pages, how to work with user story mapping. The target groups are primarily UX experts and Product Manager / Owner, working on large software projects. But also for people, who are working on larger sites or apps, the reading the book will be a profit.

The big picture: From vision to epic

To conclude, a view of the big picture: In the agile development the individual user stories are part of the so-called project backlogs. This is a collection of related stories that represent a part of the project. An example: Booking and managing hotel reservations.

Then the individual user stories come from the project backlog which are implemented in a pass-through (“Sprint”).

Most systems which have to be developed are so complex that they can be divided into several projects – then their respective story tells the so-called epic (which means something like “long history”…).

Finally the vision describes in a few sentences, where the way of the development will go: Who should buy this product, who should use it? What’s the value for users? Which properties must the product have before it can be delivered? What makes the product better than the competition (USP)? What are the time frame and budget?

Diagramm Scrum Lebenszyklus

Problems with acceptance and implementation

A problem with user stories: they are not established yet. This means, that for some customers it seems like you want to skive off the work to make proper planning and documentation.

Many customers still expect detailed mockups – or at least wireframes, which are presented as early as possible in the project. But in agile development they will occur only gradually.

In addition to that, not every costumer values the circumstance to participate in the project. It is not clear to everyone that the more and more he is involved in the development, the more the result corresponds to his ideas.

Often the usual documents are the milestones for the payment – only if for example the detailed concept exists, the customer will pay the next installment.

This means you have to make some educational work.

Use what works for your project, your clients and your team

My pragmatic advice is:

Use the techniques in the way they fit for your clients and your team. Start with:

  • Personas (see What would Walter do?), then continue with
  • Customer Journey Maps (see customer journey, user experience, Maps) and then test
  • User stories.

For projects that are very content heavy, such as pure information sites, also come along well with the classical methods.

The more features your project should offer, the more you should try to work agile.

At the end, a comforting quote from my colleague Rian van der Merwe:

Documents are not a bad thing. Poor documents are bad.

by Jens Jacobsen

www.usabilityblog.de