What is user story?
Have you ever had to transform an abstract requirement into implemented, tested, and production-ready code? Then you need a way to describe the requirement so that any person – a businessman, analyst, developer, and tester – has a general idea of the scale of the work.
User Story is a short statement of intent that describes something the system should do for the user.
Despite the fact that User Stories play a huge role that previously belonged to requirements specifications, use cases, etc., they still differ in a number of subtle but critical nuances:
- They are not a detailed description of the requirements, but rather a discussed representation of intent;
- They are short and easy to read, understandable for developers, stakeholders, and users;
- They are relatively easy to assess, so the effort required to implement 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 developed in more detail “just in time”, thus avoiding too early certainty, delays in development, piling up requirements and overly limited formulation of the solution;
- They require little or no maintenance and can be safely canceled once implemented.
So what’s the bottom line?
User story is the result of communication between business representatives, business analysts, testers and developers and equally determines how different project participants should interact with each other, and what the results of the development process should be.
