User story

About: User story is a research topic. Over the lifetime, 1078 publications have been published within this topic receiving 23717 citations.

UX Design Requirements: User Stories and Requirements

Abstract: In this chapter, UX design wants and needs discovered in usage research are codified as user stories and UX requirements. A user story is a short narrative describing a feature or capability needed by a user in a specific work role and a rationale for why it is needed, which is used as an agile UX design “requirement.” Although rarely needed in today’s projects, more formal UX design requirements can also be extracted from the usage research data, organized by subsystem, feature, etc. and documented in formal requirements statements. User stories and requirements are validated with users and stakeholders.

Chapter 12 – Storyboarding

Abstract: Publisher Summary This chapter illustrates the creation of the storyboards. Storyboards are like freeze-frame movies of the new work practice. The team draws step-by-step pictures of how people can work in their new world. Storyboards include manual steps, rough user interface components, system activity and automation, and documentation use. Storyboards generally act like high-level use cases. Storyboards are equivalent to future scenarios, to-be use cases in RUP, and the basis for user stories in the XP process. Storyboards essentially take the broad view of the vision, and work out in detail how one can accomplish specific tasks in the new design. It is important to figure out the details of how work can be done in the new system in order to ensure that there is no break in the users existing work practice. Thus, storyboards are guided by and checked against the consolidated sequences for tasks and intents that need to be supported.

Influence of Software Product Management Maturity on Usage of Artefacts in Agile Software Development

Abstract: Context: Agile software development (ASD) uses ‘agile’ artefacts such as user stories and product backlogs as well as ‘non-agile’ artefacts, for instance designs and test plans. Rationales for incorporating especially non-agile artefacts by an agile team mainly remain unknown territory. Goal: We start off to explore influences on artefacts usage, and state our research question as: To what extent does maturity relate to the usage of artefacts in ASD in software product organizations? Method: In our multiple case study 14 software product organizations were visited where software product management maturity was rated and their artefacts usage listed. Results: We found maturity to be negatively correlated with the non-agile/all artefacts ratio. In other words, the more mature software product management is, the fewer non-agile artefacts are used in ASD. Conclusions: This suggests that an organizational factor influences an agile team in its artefacts usage, contradictory to the concept of self-organizing agile teams.

On the Nature of Links between Requirements and Architectures: Case Studies on User Story Utilization in Agile Development

Abstract: Communication between requirements engineers and software architects is experienced as problematic. In this paper we present the Requirements Engineering for Software Architecture (RE4SA) model as a tool that supports the communication between these two roles. In the RE4SA model, requirements are expressed as epic stories and user stories, which are linked to modules and features, respectively, as their architectural counterparts. By applying the RE4SA model to a multi-case study, we investigate the nature of the relationships between the requirements and the architectural artifacts. Based on the gained experience, we put forward nine hypotheses for further research on the utilization of user stories in agile RE.