January 26, 2010 at 15:35Basics of user stories. Part 1. Introduction
- Transfer
Translation: Alexander Yakima ( www.enter-agile.com )
Independent consultant, agile trainer. In the IT industry since 2002. He worked as a project and program manager, as well as a sales manager for outsourcing companies and a development director for startups in Silicon Valley. In 2007-2008 he collaborated with the training center Luxoft.
Abstract:
In this article, we provide an overview of the origin and applications of user stories, which are a key mechanism in flexible development methods and serve as a conductor of customer requirements through a stream of values. In turn, user stories are a critical element in the articles “Lean and Scalable Requirements Information Model for Agile Companies” and“The big picture of company flexibility,” both articles can be found on the blog . The current article is extracted from a future book, Flexible Requirements: Lean Practices for Managing Requirements for Teams, Programs, and Enterprises, which is scheduled for publication in 2010. Special thanks to Jennifer Fawcett and Don Widrig for their contributions to the book.
About terminology (notes of the author of the translation):
The central object of the article, as the reader could already guess, is the user story, which in the original sounds like a user story. There are several different, including rather extravagant translations of this term (eg, “wish”). However, in the translation, I decided to use only practical motives, which is why we use the term “user story” in a somewhat official way and for direct calculations - “story”. The fact is that it is this term that prevails in the life of most flexible teams when working with English-speaking customers and is therefore justified.
They were at a great feast of languages, but were content with crumbs.
- Page Moth to Kostard, “The Vain Work of Love”, William Shakespeare
In agile development, a user story is a lightweight and more lively replacement for traditional means of describing requirements: functional specifications, use case descriptions, etc. In fact, one can even argue that a user story (story) is the most significant artifact in agile development, since it is a container that serves to transfer the flow of values to the user, and the essence of agile development is precisely the quick delivery of a valuable result.
Storey also serves as a metaphor for our whole approach, based on incremental delivery of values, namely:
Define a useful story - implement and test in the framework of a short iteration - demonstrate and / or deliver it to the user - receive feedback - learn information - repeat in a loop!
I have already briefly discussed user stories in the context of my wider articles: “Lean and scalable information model of requirements for flexible companies” and “General picture of company flexibility” (1) , in which, along with themes, epics and features, stories are paramount 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 that makes it possible to direct our solution directly to the needs of the user and at the same time verify the quality of the product.
In the aforementioned articles and related blog posts, I emphasized the importance of the Scrum model’s contribution to agile practices for companies, noting, for example, the very definition of the role of a product owner, which is integral to working with requirements. But we owe the very invention of user history to XP, and it is the proponents of XP that have developed the breadth and depth of this artifact. Although this is a significantly less significant “methodological crossroads” than it may seem, since user stories are usually now included in the framework of Scrum courses as a means of building a backlog and determining the composition of Sprint. Surely we should thank Mike Cohn for much of this integration, as he has worked extensively on user stories in his book User Stories Applied [see Cohn 2004],
For our purposes, we define the user story as follows:
User story is a short statement of intent that describes something that the system should do for the user.
In XP, stories are usually written by the customer, thus directly integrating the customer in the development process. In Scrum, the product often creates stories based on information from the customer, stakeholders and the team. However, in fact, any member of the team who has sufficient knowledge in the business field can create user stories, but ultimately the product of the oner solves the issue of 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 focuses their work on user-defined values rather than structurally dividing them into tasks, as is customary to do by tradition. They provide a lightweight and efficient approach to managing requirements in the system.
The user story captures the short wording of the function on the 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 developed through dialogue and acceptance criteria by the team and the product owner.
User stories help bridge the gap between developers and users.
In agile development, the developer must be able to communicate in the user's language, and not the user - in the technical language. Effective communication is the key to everything and therefore we just need a common language. Storey just provides a common language for understanding between the user and the technical team.
Bill Wake, one of the creators of XP, describes this as follows (2):
Pidgin is a simplified language commonly used in commerce that allows people who cannot communicate in their own language to work together nonetheless. User stories act in a similar way. We do not expect from the customer or users the exact same vision of the system as the developers; Stories act like pidgin, where both parties can always agree to work together effectively.
In the case of user stories, we do not 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 plays a huge part in the role that previously belonged to the requirements specifications (SRS), use cases, etc., they nevertheless noticeably differ in a number of subtle but critical nuances:
[CONTINUED]
Literature
Cohn, Mike. 2004. User Stories Applied: For Agile Software Development. Boston, MA: Addison-Wesley.
REFERENCES:
Independent consultant, agile trainer. In the IT industry since 2002. He worked as a project and program manager, as well as a sales manager for outsourcing companies and a development director for startups in Silicon Valley. In 2007-2008 he collaborated with the training center Luxoft.
Abstract:
In this article, we provide an overview of the origin and applications of user stories, which are a key mechanism in flexible development methods and serve as a conductor of customer requirements through a stream of values. In turn, user stories are a critical element in the articles “Lean and Scalable Requirements Information Model for Agile Companies” and“The big picture of company flexibility,” both articles can be found on the blog . The current article is extracted from a future book, Flexible Requirements: Lean Practices for Managing Requirements for Teams, Programs, and Enterprises, which is scheduled for publication in 2010. Special thanks to Jennifer Fawcett and Don Widrig for their contributions to the book.
About terminology (notes of the author of the translation):
The central object of the article, as the reader could already guess, is the user story, which in the original sounds like a user story. There are several different, including rather extravagant translations of this term (eg, “wish”). However, in the translation, I decided to use only practical motives, which is why we use the term “user story” in a somewhat official way and for direct calculations - “story”. The fact is that it is this term that prevails in the life of most flexible teams when working with English-speaking customers and is therefore justified.
Custom Story Basics
They were at a great feast of languages, but were content with crumbs.
- Page Moth to Kostard, “The Vain Work of Love”, William Shakespeare
Introduction
In agile development, a user story is a lightweight and more lively replacement for traditional means of describing requirements: functional specifications, use case descriptions, etc. In fact, one can even argue that a user story (story) is the most significant artifact in agile development, since it is a container that serves to transfer the flow of values to the user, and the essence of agile development is precisely the quick delivery of a valuable result.
Storey also serves as a metaphor for our whole approach, based on incremental delivery of values, namely:
Define a useful story - implement and test in the framework of a short iteration - demonstrate and / or deliver it to the user - receive feedback - learn information - repeat in a loop!
I have already briefly discussed user stories in the context of my wider articles: “Lean and scalable information model of requirements for flexible companies” and “General picture of company flexibility” (1) , in which, along with themes, epics and features, stories are paramount 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 that makes it possible to direct our solution directly to the needs of the user and at the same time verify the quality of the product.
User Stories: Overview
In the aforementioned articles and related blog posts, I emphasized the importance of the Scrum model’s contribution to agile practices for companies, noting, for example, the very definition of the role of a product owner, which is integral to working with requirements. But we owe the very invention of user history to XP, and it is the proponents of XP that have developed the breadth and depth of this artifact. Although this is a significantly less significant “methodological crossroads” than it may seem, since user stories are usually now included in the framework of Scrum courses as a means of building a backlog and determining the composition of Sprint. Surely we should thank Mike Cohn for much of this integration, as he has worked extensively on user stories in his book User Stories Applied [see Cohn 2004],
For our purposes, we define the user story as follows:
User story is a short statement of intent that describes something that the system should do for the user.
In XP, stories are usually written by the customer, thus directly integrating the customer in the development process. In Scrum, the product often creates stories based on information from the customer, stakeholders and the team. However, in fact, any member of the team who has sufficient knowledge in the business field can create user stories, but ultimately the product of the oner solves the issue of 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 focuses their work on user-defined values rather than structurally dividing them into tasks, as is customary to do by tradition. They provide a lightweight and efficient approach to managing requirements in the system.
The user story captures the short wording of the function on the card or, possibly, using an online tool.
Examples:
- Login to my energy monitoring portal
- View daily intake
- Check my current rate
Details of the behavior of the system do not appear in this short formulation, but are left for later and developed through dialogue and acceptance criteria by the team and the product owner.
User stories help bridge the gap between developers and users.
In agile development, the developer must be able to communicate in the user's language, and not the user - in the technical language. Effective communication is the key to everything and therefore we just need a common language. Storey just provides a common language for understanding between the user and the technical team.
Bill Wake, one of the creators of XP, describes this as follows (2):
Pidgin is a simplified language commonly used in commerce that allows people who cannot communicate in their own language to work together nonetheless. User stories act in a similar way. We do not expect from the customer or users the exact same vision of the system as the developers; Stories act like pidgin, where both parties can always agree to work together effectively.
In the case of user stories, we do not 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 plays a huge part in the role that previously belonged to the requirements specifications (SRS), use cases, etc., they nevertheless 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 represent a discussion of intent rather (something like this needs to be done)
- 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 estimate, so the effort required for implementation can be quickly determined.
- They do not take up huge, bulky 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 developed in more detail “on time”, thus avoiding too early certainty, delays in development, piling up requirements and overly limited formulation of the decision
- They require a minimum or do not require accompaniment at all and can be safely canceled after implementation (3)
[CONTINUED]
Literature
Cohn, Mike. 2004. User Stories Applied: For Agile Software Development. Boston, MA: Addison-Wesley.
REFERENCES:
- 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 the details necessary for regression testing.