As professional developers, our role is to write high quality code within our applications. Yet this is worthless if it does not provide any value to our customers.
There are not much companies that will hire you to let you work on whatever you want. These businesses have customers that need new features and improvements in the software they buy and use.
It most cases you will work in an industry you know nothing, or almost nothing about. But don’t worry, you will work with people who know it, the business analysts. They know how to provide value for their customers and they need talents to implement it: YOU! You form a whole team.
In order to ease the specification and especially the prioritization of development in an “agile” environment, you can rely on user stories.
User Story
A user story describes a single requirement for the system. It is expressed by the business team and it generally written as a sentence matching the following format:
As a <role>, I want <goal/desire> so that <benefit>
The details are not defined within the sentence because they are likely to change with time even if the main goal will not. Details are discussed during conversations between the business analysts and the development team.
The use of user stories allow the developers to be able to provide a low risk estimate and by extension a budget for the feature. It is focused on the user needs, specific technology details should be excluded (data base schema, algorithm, …).
The role
In the sentence describing a user story a role is defined. By doing so you are able to detect the user of the system. It is likely the person who will know all the details you need to complete the task.
If the user story needs a new User Interface (U.I.) and this person is the final user of it, you should ask him how he wants to use it. Because I think that a UI providing the goal of the user story but with a really bad User Experience (U.X.) is not as valuable as it should be.
The goal
In a user story the goal is the new feature that needs to be created. It defines what the final customer/user wants and needs. This is the part of the system that needs to be well crafted, from a code perspective and from a user experience perspective (see previous section).
The benefit
The last part of the user story describes the benefit. This way you can understand the value it provides to the customers/clients. It can also describes the final result and if you know it, you can test it!
If the benefit of a user story is hard to write down maybe it means that it is not as valuable as you think it is. And therefore there might be others user stories to prioritize first.
In an agile environment such as Extreme Programming (X.P.) the use of user stories allow the business analysts to express their needs for the customers without writing an entire documentation containing every details. They are focused on the user, the goal and the benefit. This way the development team should be able to properly estimate it and they gather the details using a good communication in the whole team.
See you next time!
Image credits:
Coding Journeyman 