Read it in 0 Mins
Writing requirements as user stories is the most common and accepted form of documenting requirements in an Agile project. Moreover, product backlogs are made up of requirements written as user stories most of the time. User stories are considered to be simple to create, clear and concise and easily understood, and considered as convenient to update and maintain.
User stories are written following a specific format, making it universally acceptable across the software industry. User stories follow the 3C’s format described below and focus on the business value each story provides to the user. Also, to know more, read about user stories examples.
3C’s of user stories
As a [user | role | persona]
I must be able to [functionality]
So that I get [benefit | business value]
As best practice, we try to generalize by writing the requirement as required by a user group or role. For this it is imperative that ‘user research’ is done to capture the actual behaviours, opinions and attitudes of the users and be documented as ‘user persona’ documentation.
The functionality is documented with the keyword ‘must’ which stresses the fact that this is the exact feature required by the user. Some document the functionality with keywords such as ‘will’, ‘shall’, ‘would’, ‘should’ etc which actually leaves a bit of uncertainty and must be avoided at all times.
When documenting the benefit or the business value it is always good to keep in mind the ROI, cost saving, efficiency etc expected from the feature described.
The user story as we can see is a combination of ‘who’, ‘what’ and ‘why’ which together gives out a meaningful story. The user story defines functionality from a business perspective and does not define how the problem shall be solved.
A user story and its possible acceptance criteria can be as below.
As a backpacker I must be able to search for rest houses so that I can identify a suitable place for my stay.
Search for rest house by location, price range, facilities, cuisine, surroundings, rating
But writing acceptance criteria in detail like this is never a good idea. There is no such thing as a complete or exact specification. A user expectation may not be defined in exact detail or accuracy all the time. Space must be kept for the team to have a good conversation to uncover hidden aspects about the requirements. As we can see from the above example itself we are unable to confidently say that we’ve covered the requirement to its entirety. For example, ‘what are the key information to be displayed and be available as a single view?’.
With this approach, the development team is never involved in story definition. They end up being spoon-fed, take the criteria one by one and implement as is. The main reason being they being able to blame the poor business analyst for not detailing the requirements adequately. It should ideally be a case where the requirements and the entire organizational change is driven by the business analyst and to have him involved collaborating and communicating identifying the change required to meet the customer needs throughout the life of the project.
So, what is a better approach?
As explained before, the user story is about striking a conversation. Keep the story simple and short stressing on the expected behaviour and impact. These can be written as ‘Conditions of Satisfaction’. For example, ‘The backpacker can enjoy a nights stay after a tedious day at a budget hotel at a convenient location’.
Now, the team as a whole will be focused on solving the ‘problem defined’ by having a more user centric conversation. More user research will be done to identify solutions to address the user needs and in determining new ways of delivering more value. Discussion may take longer but ultimately, the team shall produce winning solutions that are geared to solving the real problem at hand.
So, it is up to you now to use your user stories wisely. ☺
Avail your free 1:1 mentorship session.