The basics of user stories. Part 1. Introduction
Translation: Alexander Yakima ( www.enter-agile.com )
Independent consultant, agile-coach. In the IT industry since 2002. He worked as a project manager, program manager, as well as a site manager in outsourcing companies and as a development director at Silicon Valley startups. In 2007-2008 he collaborated with the training center Luxoft.
Annotation:
In this article, we provide an overview of the origins and applications of user stories, which are a key mechanism in flexible development methods and serve to guide customer requirements through the flow of values. In turn, user stories are a critical element in the articles “Leaning and Scalable Information Requirements Model for Flexible Companies” and “General Picture of Company Flexibility” , both articles can be found on the blog . The current article is extracted from the future book, Flexible Requirements: Lean Practices of Requirements Management for Teams, Programs and Enterprises, which is scheduled for 2010. Special thanks to Jennifer Fawcett and Don Widrig for their contributions to the work on the book.
About terminology (notes by the author of the translation):
The central object of the article, as the reader could already guess, is the user story, originally sounding as a user story. There are several different, including rather extravagant translations of this term (for example, “wish”). However, when translating, I decided to use only practical motives, which is why we use the term “user story” in a somewhat official manner and for direct calculations - “story”. The fact is that this term prevails in the life of the majority of flexible teams when working with English-speaking customers and is therefore fully justified.
')
They were at the great feast of tongues, but were content with crumbs.
- Page Mole to Costard, “Wasted Labor of Love”, William Shakespeare
In agile development, a user story is a lightweight and more vivid substitute for traditional means of describing requirements: functional specifications, descriptions of use cases (use cases), etc. In fact, it can even be argued that user story (story) is the most significant artifact in agile development, since it is a container that serves to transfer the stream of values ​​to the user, and the essence of agile development lies precisely in the rapid delivery of valuable results.
Storey also serves as a metaphor for our entire approach based on incremental value delivery, namely:
To determine the useful story - to implement and test in a short iteration - to demonstrate and / or deliver it to the user - to receive feedback - to assimilate information - to repeat in a cycle!
I have already briefly described the discussion of user stories in the context of my broader articles: “Lean and Scalable Information Model of Requirements for Flexible Companies” and “General Picture of Company Flexibility” (1) , which along with themes, epics and features, are the primary artifacts requirements used by flexible teams.
In this article, we will describe user stories in more detail, since it is here that we will reveal one of the key flexible practices, which makes it possible to direct our solution directly to the user's needs and at the same time ascertain the quality of the product.
In the aforementioned articles and related publications in the blog, I emphasized the importance of the contribution of the Scrum model to flexible practices for companies, noting, for example, the very definition of the product owner role, which is indivisible in relation to the work with requirements. But by the invention of the user history, we owe XP and it was the XP proponents who developed the entire breadth and depth of this artifact. Although this is a much less significant “methodological crossroads” than it might seem, since user stories now usually fall within the scope of Scrum courses as a means of building backlog and determining the composition of Sprint. Surely we should thank Mike Cohn for most of this integration, as he worked out user stories thoroughly in his User Stories Applied book [see Cohn 2004], and was very active in the Scrum Alliance community.
For our purposes, we define a user story like this:
A user story is a short statement of intent describing something the system should do for the user.
In XP, stories are usually written by the customer, thus directly integrating the customer into the development process. In Skram, a product owner often creates a story, taking into account information from the customer, stakeholders and the team. However, in fact, any team member with sufficient knowledge in the business area can create user stories, but ultimately the product manager decides on accepting and prioritizing potential stories in the product backlog.
User stories are a means of defining system behavior so that it is understandable to both developers and users. Storey concentrates work on user-defined values, rather than on a structural breakdown into tasks, as is customarily done by virtue of tradition. They provide a lightweight and efficient approach to managing system requirements.
A user story captures a short statement of the function on a card or, possibly, using an online tool.
Examples:
Details of the behavior of the system do not appear in this short formulation, but are left for later and are developed through dialogue and acceptance criteria by the team and product manager.
User stories help bridge the gap between developers and users.
In agile development, the developer should be able to communicate in the user's language, and not the user - speak in a technical language. Effective communication is the key to everything and therefore we just need a common language. Storey provides a common language for understanding between the user and the technical team.
Bill Wake, one of the creators of XP, describes it as follows (2):
Pidgin (pidgin) - a simplified language commonly used in commerce, allows people who can not communicate in their native language, nevertheless work together. User stories act in a similar way. We do not expect from the customer or users exactly the same vision of the system as that of the developers; The storytells act like a pidgin, where both parties can always agree to work together effectively.
In the case of user stories, we don’t need to understand each other’s language at the level of skill required to write sonnets; we just need to understand each other enough to know when we have reached an agreement!
Despite the fact that the story play in a huge degree the role that previously belonged to the requirements specifications (SRS), usage scenarios, etc., they still noticeably differ in a number of subtle but critical nuances:
[TO BE CONTINUED]
Literature
Cohn, Mike. 2004. User Stories Applied: For Agile Software Development. Boston, MA: Addison-Wesley.
Links:
Independent consultant, agile-coach. In the IT industry since 2002. He worked as a project manager, program manager, as well as a site manager in outsourcing companies and as a development director at Silicon Valley startups. In 2007-2008 he collaborated with the training center Luxoft.
Annotation:
In this article, we provide an overview of the origins and applications of user stories, which are a key mechanism in flexible development methods and serve to guide customer requirements through the flow of values. In turn, user stories are a critical element in the articles “Leaning and Scalable Information Requirements Model for Flexible Companies” and “General Picture of Company Flexibility” , both articles can be found on the blog . The current article is extracted from the future book, Flexible Requirements: Lean Practices of Requirements Management for Teams, Programs and Enterprises, which is scheduled for 2010. Special thanks to Jennifer Fawcett and Don Widrig for their contributions to the work on the book.
About terminology (notes by the author of the translation):
The central object of the article, as the reader could already guess, is the user story, originally sounding as a user story. There are several different, including rather extravagant translations of this term (for example, “wish”). However, when translating, I decided to use only practical motives, which is why we use the term “user story” in a somewhat official manner and for direct calculations - “story”. The fact is that this term prevails in the life of the majority of flexible teams when working with English-speaking customers and is therefore fully justified.
')
User story basics
They were at the great feast of tongues, but were content with crumbs.
- Page Mole to Costard, “Wasted Labor of Love”, William Shakespeare
Introduction
In agile development, a user story is a lightweight and more vivid substitute for traditional means of describing requirements: functional specifications, descriptions of use cases (use cases), etc. In fact, it can even be argued that user story (story) is the most significant artifact in agile development, since it is a container that serves to transfer the stream of values ​​to the user, and the essence of agile development lies precisely in the rapid delivery of valuable results.
Storey also serves as a metaphor for our entire approach based on incremental value delivery, namely:
To determine the useful story - to implement and test in a short iteration - to demonstrate and / or deliver it to the user - to receive feedback - to assimilate information - to repeat in a cycle!
I have already briefly described the discussion of user stories in the context of my broader articles: “Lean and Scalable Information Model of Requirements for Flexible Companies” and “General Picture of Company Flexibility” (1) , which along with themes, epics and features, are the primary artifacts requirements used by flexible teams.
In this article, we will describe user stories in more detail, since it is here that we will reveal one of the key flexible practices, which makes it possible to direct our solution directly to the user's needs and at the same time ascertain the quality of the product.
User stories: review
In the aforementioned articles and related publications in the blog, I emphasized the importance of the contribution of the Scrum model to flexible practices for companies, noting, for example, the very definition of the product owner role, which is indivisible in relation to the work with requirements. But by the invention of the user history, we owe XP and it was the XP proponents who developed the entire breadth and depth of this artifact. Although this is a much less significant “methodological crossroads” than it might seem, since user stories now usually fall within the scope of Scrum courses as a means of building backlog and determining the composition of Sprint. Surely we should thank Mike Cohn for most of this integration, as he worked out user stories thoroughly in his User Stories Applied book [see Cohn 2004], and was very active in the Scrum Alliance community.
For our purposes, we define a user story like this:
A user story is a short statement of intent describing something the system should do for the user.
In XP, stories are usually written by the customer, thus directly integrating the customer into the development process. In Skram, a product owner often creates a story, taking into account information from the customer, stakeholders and the team. However, in fact, any team member with sufficient knowledge in the business area can create user stories, but ultimately the product manager decides on accepting and prioritizing potential stories in the product backlog.
User stories are a means of defining system behavior so that it is understandable to both developers and users. Storey concentrates work on user-defined values, rather than on a structural breakdown into tasks, as is customarily done by virtue of tradition. They provide a lightweight and efficient approach to managing system requirements.
A user story captures a short statement of the function on a card or, possibly, using an online tool.
Examples:
- Log in to my energy monitoring portal
- View daily consumption
- Check my current rate
Details of the behavior of the system do not appear in this short formulation, but are left for later and are developed through dialogue and acceptance criteria by the team and product manager.
User stories help bridge the gap between developers and users.
In agile development, the developer should be able to communicate in the user's language, and not the user - speak in a technical language. Effective communication is the key to everything and therefore we just need a common language. Storey provides a common language for understanding between the user and the technical team.
Bill Wake, one of the creators of XP, describes it as follows (2):
Pidgin (pidgin) - a simplified language commonly used in commerce, allows people who can not communicate in their native language, nevertheless work together. User stories act in a similar way. We do not expect from the customer or users exactly the same vision of the system as that of the developers; The storytells act like a pidgin, where both parties can always agree to work together effectively.
In the case of user stories, we don’t need to understand each other’s language at the level of skill required to write sonnets; we just need to understand each other enough to know when we have reached an agreement!
User stories are not requirements
Despite the fact that the story play in a huge degree the role that previously belonged to the requirements specifications (SRS), usage scenarios, etc., they still noticeably differ in a number of subtle but critical nuances:
- They are not a detailed description of the requirements (that is, what the system should do), but rather a discussed presentation of intent (you need to do something like this)
- They are short and easy to read, understandable to developers, stakeholders and users.
- They represent small increments of valuable functionality that can be implemented within a few days or weeks.
- They are relatively easy to assess, so the effort required for implementation can be quickly identified.
- They do not take up huge, cumbersome documents, but rather are organized into lists that are easier to organize and reorder as new information arrives.
- They are not detailed at the very beginning of the project, but are already being developed in more detail “just in time”, thus avoiding too early certainty, delays in the development, clutter of requirements and overly limited formulation of the decision
- They require minimal or no maintenance and can be safely canceled after implementation (3)
[TO BE CONTINUED]
Literature
Cohn, Mike. 2004. User Stories Applied: For Agile Software Development. Boston, MA: Addison-Wesley.
Links:
- www.scalingsoftwareagility.wordpress.com
- xp123.com/xplor/xp0308/index.shtml
- This is the task of developing and supporting acceptance tests that determine the behavior of the system in detail for regression testing.
Source: https://habr.com/ru/post/82066/
All Articles