Rationale and justification for different job and user story modeling

Elena Karelina

Nowadays in the majority of agile methods user stories are the main software requirements artifact. In the literature ([1], [2]) a user story is defined as a way of describing a requirement to the developed software system in natural language in such a way that it is clear to the end user. Basically, a user story consists of three parts: 1. WHO clause: defines who uses the system (e. g. the category of the user or their role in the system). 2. WHAT clause: defines what is done with help of the system. 3. WHY close: defines why the system is used and what user’s need the system satisfies. The most common user story template is: As <WHO> I want <WHAT> so that I <WHY>. Sometimes this template is called 3Ws template. There exist a lot of modifications of this template which substitute the words WHO, WHAT and WHY with more concrete terms. For example, “role” or “type of user” can be used instead of WHO and “feature” or “action” can be used instead of WHAT. Nevertheless, [3] and [4] describe two other user story templates. The first one has the following structure: In order to <receive a benefit> as a <role> I want <goal> (hunting the value template). The other template is: As <WHO> <WHEN> <WHERE> I <WHAT> because <WHY> (5Ws template). This essay focuses on considering the aforementioned three user story models.

The template requires determination of WHO, WHAT and WHY clauses. According to the research about the terms in 3Ws template ([5]), in the majority of 3Ws templates it is necessary to name the user’s role in the system in WHY clause. It is important to emphasize on the user’s role because all system’s users can be divided into categories and pointing which user category need the feature under consideration leads to better understanding of the requirements. Yet still there are some templates where the user’s role in the system is not mentioned. WHAT clause describes the feature itself, e. g. what is done by the system. This clause determines a functional requirement to the system which should be implemented. WHY clause helps to understand the reasons for using the feature and what profit will be achieved by using the system. This leads to better understanding of the user’s motives and gives some ideas of how the feature can be implemented in order to fit the users in the best way. There exist some templates that exclude WHY or WHO clauses in order to simplify a user story but such simplifying may cause loss of some important information. 3Ws template has been being used for about twenty years and has become an essential part of formulating software requirements in agile teams so it has proved its validity. But why this template has become so popular? First of all, it is rather simple and user stories written in such way are clear to all members of the developers’ team and other stakeholders and makes communication between them easier which fits agile manifest. Another point to keep in mind is the personalized form of the user story which is mentioned in [6]. As the template contains personal pronoun I, this inclines the person who writes the user story to empathy and feeling themselves in place of the described user. Consequently, the user story writer can better imagine the context of system usage and formulate the requirement in a more precise way.

This template emphasizes on the business value of the system’s feature and does not allow removing WHY and WHO clauses. It aims at making the user story writer to concentrate on reasons why and by what kind of person the software product is used. This is likely to help the writer to understand the usage context better and provide the developers team with additional ideas about how the described feature should be implemented. As this template makes accent on the usage context it is more likely to be used when there are some difficulties in specifying exact software requirements and additional modeling needs to be done to come up to determining the feature precisely. “Hunting the value” template also keeps personalized way of expressing the user story so that it also leads to more empathy form those who write user stories.

The template introduces two additional clauses (WHEN and WHERE) to 3Ws user story template. [7] provides some practical recommendations how to use 5Ws template. Describing WHERE clause is aimed at acquiring better understanding of the circumstances under that the system is used and as a result it leads to more precise formulating of the requirement to the system. Formulating WHEN clause helps to realize what has caused the user’s need to use the system and also provides more deep understanding and writing the requirements. Moreover, WHEN clause may be described in both absolute and relevant time, for instance, “after authorization”. In this case formulating WHEN clause can be useful in terms of writing the system’s scenarios and use cases. As 5Ws template provides deeper understanding of the requirements it leads to more complex user story structure. This can be considered as the template’s disadvantage because user story should be short and easy to understand.

This essay concentrates on describing the most frequently used user story templates described in the literature and provides the reasons for using all parts of the template. As it can be concluded, all user story templates aimed at forming better understanding of the system’s realization and providing brief but clear description of the software requirements and the usage context. Some templates, for instance, 5Ws template focus on more details of the usage context but they become more complex and not so easy to percept. Some other templates, for example reduced versions of 3Ws template tend to omit some information in order to make the user story utterly brief. Another kind of template (hunting the value) mostly focuses on the business value of the system than on the required feature. These templates can be used in different cases depending on the purposes of writing user stories: in some situations it is more relevant to provide features with additional context or even highlight the context but in the other situations brevity could be the first priority.

1. Trkman M. et al. Impact of the conceptual model's representation format on identifying and understanding user stories Information and software technology. – 2019. – Т. 116. – С. 106169.
2. Wautelet Y. et al. Unifying and extending user story models International Conference on Advanced Information Systems Engineering. – Springer, Cham, 2014. – С. 211-225.
3. Samedi H. Impact of unified user-story-based modeling on agile methods: aspects on requirements, design and life cycle management Doctoral thesis Université catholique de Louvain, Louvain La Neuve, Belgique. Link: https://orbi.uliege.be/handle/2268/228630 (access date: 11.10.2021)
4. Article about user stories in Wikipedia. Link: https://en.wikipedia.org/wiki/User_story (access date: 17.10.2021).
5. Wautelet Y. et al. Bridging user story sets with the use case model International Conference on Conceptual Modeling. – Springer, Cham, 2016. – С. 127-138.
6. Blog post “Why the three-part user story template works so well”. Link: https://www.mountaingoatsoftware.com/blog/why-the-three-part-user-story-template-works-so-well (access date: 11.10.2021).
7. Blog post “writing user stories the 5 Ws way”. Link: http://blog.agilejedi.com/2008/03/writing-user-stories-5-ws-way-writing.html (access date: 17.10.2021)