User Story – Useful Technique But Not Always Optimal?
Receive free IIBA updates and exclusive content!
User Story is a term unambiguously related to Agile methodology of software development. When we think of Scrum we usually associate it with User Story and the other way around.
What is a User Story?
Certainly, it is a popular and widely applied technique used to characterize requirements. It describes in a short and concise way what a given type of a user (actor) wants to do and why. In other words, it revolves around the value being delivered.
Sometimes User Story is understood narrowly, only as its core part which is called “Statement of Value”. This is a statement describing what value is being delivered when a particular story is implemented. Let’s first address that part.
Statement of Value
Usually a “Statement of value” is based on one of few templates. Probably the most popular is:
“As a <who?> I need to <what?>, so that <why?>.”
This gives us a structure of 3 main elements:
- Actor <who?> – Indicates a particular user type (designated actor interacting with the system, for example, Administrator, Customer, Supplier, etc.). Usually various groups of users may be identified, who use the system for different reasons, having different levels of permissions.
- Action <what?> – A description of what a designated actor aims to do in the system, description of performed activity.
- Value <why?> – Specifies the reason behind the implementation describing the delivered value. Unfortunately, this is the element prone to errors as it is often not presented properly or sometimes even skipped. This, in my view, poses a serious issue as the business value to be delivered is lost from sight, while it should be at the centre of our attention.
Other elements of User Story
The remaining elements are:
- Title – Optional. It is usually a short, one sentenced formulation of a User Story’s goal.
- Conversation – User Story should be treated merely as an introduction to further discussion with project team and other stakeholders, a basis for further consideration and related modeling. This element should not be treated as a visible, written down fragment of text. It should rather underline that each story requires a wider conversation.
- Acceptance criteria – They help to define the User Story and its boundaries. These are conditions which should be met so it can be verified if the required value has been delivered.
Is User Story useful in every case?
User Story is a tool to describe in short and concise manner a need of a particular user, which may be additionally clarified by the acceptance criteria. Then the User Story should be subject to further discussion and consideration aimed at finding appropriate solution. It all sounds good, so good in fact that this technique if often overused.
I’ve heard opinions that Scrum does not recognize the documentation, or the only allowed form of it is the User Story. Of course, this view is wrong.
In one of the teams I have worked with as a Business Analyst in the past I had the following situation: When we reached a moment when the system developed by my team was to integrate with a system developed by another team, I asked the other Business Analyst to share the documentation so I could learn their part, its functionalities, available interface, etc. I received a list of 153 User Stories related to the development of their part… Of course, the User Stories were developed over several years, and those which were created later modified earlier implementations also described in User Stories. Therefore, creating a consistent vision of the system based on the available list seemed like an extremely uneasy task. This is a clear example that a User Story, while usually very useful, should not be used for every purpose.
Where to use a User Story?
To put it short: whenever you need to store requirements on a short term basis and where there is a need to emphasize the value being delivered. Other than that, User Stories are used as an introduction to further discussion in order to find a common understanding and continue to work on creating a solution model.
Above that, due to their specific nature allowing to divide work into small, concise functionalities or quality requirements, User Stories may be also used to:
- Discussion on priorities
- Work estimation
- Planning of product development and its versioning
- Mapping of high level requirements
- Designing acceptance testing
- Tracking and reporting of work progress
Where not to use a User Story?
First of all, User Story should not be used as a long term storage of requirements. They prove not to be a good base to create a documentation used to develop and maintain a product. Mostly because basing only on User Stories and without any additional documentation, it is very difficult to recreate current state of the system.
It is important to remember, that a User Story alone, without any accompanying context is usually not enough for the development team to work effectively. They require broader scope to increase their level of understanding of the implemented change, the goal and impact on individual components of the system. It could be provided using other techniques and different forms of documentation.
My recommendations
- Use the User Stories in accordance with their designation: to document requirements for a short term use
- Treat them as an introduction to further discussion and not as a fixed and unnegotiable requirements
- Do not try to fit everything into a User Story. Support it with a documentation in a different form, more suitable for your needs, such as diagrams, interface mock-ups, use case description, etc.
- For long term maintenance of requirements use other, more appropriate techniques
- Always remember about the correct description of the value to be delivered (see the last element of User Story structure described above: Statement of Value)
About the Author:
Radek has gained his professional experience working as a Business Analyst and Product Owner. He is a practitioner who worked with various IT teams delivering projects in organizations of different sizes, ranging from small start-ups to international corporations.
Radek is a member of the International Institute of Business Analysis Poland Chapter. He hold the following certificates, issued by the IIBA: CBAP (Certified Business Analysis Professional), CCBA (Certificate of Capability in Business Analysis) and IIBA-AAC (Agile Analysis Certification).
Radek cooperates with various companies and institutions, conducting trainings and workshops on Business Analysis.
References:
A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide). Version 3.