When choosing a software provider to create the web or desktop solution your company needs, understanding and crafting effective user stories is indeed key for communication. However, this may be easier said than done. The gap between programmers and customers can quickly become apparent and is often a challenge to master, as most customers are unprepared to discuss their projects from a strictly technical point of view.
In order to get past these difficulties and effectively relay their requirements, some companies resort to UML or workflow diagrams, while yet others go for UI sketches and lengthy free text descriptions.
At Software Planet Group, however, we think both customers and developers should always be on the same page, and speak the same language (see our article on the system metaphor for more on this subject). This is why wherever we can, we aim to simplify the management of requirements, using tried-and-true techniques that enable us to quickly determine the full scope of a project, estimate and re-estimate particular features and releases.
For this reason — and because we strongly believe in the principles of the Agile manifesto — we make use of User Stories, a uniquely Agile approach to defining requirements.
Each story consists of both valuable and estimable features which are tiny enough to be implemented within not weeks, but days. In this way, our customers are able to use a basic story format that can easily relay their needs in non-technical, everyday language; perfectly understandable to clients and engineers:
As a <type of user>, I can/want <some goal/action> so that <some reason, benefit>
Because each story is written from the viewpoint of potential users in roles or personas created in partnership with our customers, they are able to define exactly what end users will be trying to achieve and why. As a result, one may end up with stories very similar to the ones below:
- As a teacher, I want to organise my lesson plans by topic and age group, so that I can handily refer to them in the future if needed
- As a writer, I can hide all menus and buttons, so that no distractions will remain on the screen
- As a comic, I want to ensure that my jokes are always kept private so that other comedians will be unable to steal my ideas
- As a cook, I want to be able to rate recipes from 1 to 5 stars so that my favourite ones will be at hand in time for a dinner party
- As a marketer, I can find and browse through successful campaigns so that I can gain inspiration for my own concepts and endeavours
Each mini-narrative is then placed in a backlog for all to see, and prioritised according to its value.
It is worth pointing out that requirements, acceptance criteria and priorities are all very important artefacts whose sole privilege of specification resides with the customer. So for clarity’s sake, all parties must recognise that when programmers are asked to prepare these documents, it is the customer who remains responsible for their correctness — or incorrectness.
Thus, user stories are prioritised directly by our customers; and as a bonus, will even allow developers to implement requirements without any dependencies at all. This means instead of being given non-essential, low-priority user login and registration functionality, as is common in the initial stages of development, you are able to attain the very core features of your project (i.e. financial reports, content management, document processing, etc.).
Another important differentiator of working with user stories is the use of acceptance criteria — alternatively known as the definition of done. These aim to provide the necessary conditions that must first be met in order for a story to be regarded as complete. This is useful to everyone involved, as it helps to develop a shared understanding of how fragments of functionality will be verified and accepted. Taking the cook story example from earlier, for instance, plausible acceptance criteria could be any or all of the following:
1. Rate from 1 to 5 starts
2. Unable to rate twice
3. See my previous ratings
4. Cannot rate my own recipes
5. See animation for every possible rating
Beyond this, nonetheless, although some may worry about seemingly vital details being omitted from user stories, any further data is intentionally left out. This gives developers just enough information to appropriately estimate the complexity of each feature, while concurrently leaving room for productive, fruitful discussion.
In fact, with the more nuanced requirements, we may even deliberately mark our stories with the initials TBD (to be discussed), giving them the opportunity to be further fleshed out and ensuring we will not stray from our customer’s mental blueprint. In similar fashion, we may also group stories by broader functionality, such as authorisation, user management and reporting, to create what is referred to as Epics.
Summary
In summary, however, each and every user story is essentially an open invitation for a future conversation with you, allowing our customers to efficiently prioritise and manage their project’s scope, without bogging down developers in bewildering, superfluous details.
By switching to user stories, you can quickly compare costs and estimates from different software providers and make vastly more informed decisions about the companies you choose to work with.
