Recently my friend Zhang San asked me: "Epic, features, user stories, must they be related to use together?"
My answer is: Of course not. But to really explain this answer clearly, I also need to explain some concepts.
Product backlog
In the Scrum Guide, the Product Backlog is an ordered list of all the content required by the product, and it is the only entry for any changes to the product. As long as the product still exists, then the product to-do will exist, it will continue to change to adapt to product development. Product to-do items include features, functions, requirements, enhancements, and fixes. However, when practicing Scrum, many teams are more accustomed to replacing them with epics. ), Features (Feature), stories (User Story), tasks (Task) and defects (Bug). These matters constitute a series of changes to the product in the future.
As the value of the product grows, the product backlog will become larger and more detailed. Demands will never stop. These demands may come from business scenarios, market requirements, technical updates, etc. The product owner needs to refine the product to-do items with the assistance of the development team. The details include adding details, estimating and sorting. A lot of historical experience proves that only 20% of the functions of a product are commonly used functions, and 40% of the functions have never been used. Therefore, through the management of product backlogs, the development resources can be effectively focused on the most profitable work.
Sprint and increment
The core of Scrum is Sprint, which completes a product increment that can be released in a fixed cycle. At the beginning of Sprint, we must first determine the to-do items of this Sprint. These to-do items are derived from product to-do items and are usually determined according to priority. At the end of the Sprint, all the work completed in this Sprint should be in a usable state. The newly added product features, functions, and defect fixes are an increment of this product. The product owner decides whether to release or not to release.
Increment is another step towards the goal, it means that part of the product to-do list has been completed. One Sprint followed another Sprint, one increment followed another increment.
User stories
Strictly speaking, there is no user story in Scrum. The user story comes from the goat software of Scrum co-founder Mike Cohen. Its core lies in a brief description of the function from the perspective of people who desire new functions. It usually follows this template:
As <user type>, I want <some goals> so that <some reasons>.
User stories are usually written on sticky notes or cards for everyone to discuss. It shifts the preparation of complex requirements documents to discuss requirements, such discussions can effectively avoid inconsistent understanding.
In addition, the user story should be small enough to be completed in a Sprint. My personal recommendation is a workload of 0-3 days (using time to describe the scale is inappropriate, here is just for convenience to explain the size, interested friends can see My last article), this can guarantee the team speed.
epic
Epic can be understood as a very large user story, which may take several months to complete. It cannot be put into a Sprint, but it is a real demand. Epic is like a placeholder. It is first placed in the product agency. When appropriate, it will be split into many small user stories. These appropriately sized user stories will replace Epic in Sprint.
There are two key points in understanding epics: 1. It is very large, 2. I have not thought about the details.
characteristic
The scale of the feature is between epic and user stories, it is a collection of related user stories, these user stories form a complete function. When creating a feature, it is usually already clearer about the details, and related user stories are related through a feature.
An iteration does not mean a version. There are many scenarios where multiple iterations correspond to a version. When a product is released, it is often more concerned about the completion of the feature.
There are also two key points to understand the characteristics: 1. It is relatively large, 2. I have figured out the details inside.
Epic & Features & User Story
In complex business scenarios, epics, features, and user stories can make product backlogs more intuitive. They can build a tree structure:
I return to Zhang San's question. Epic, features, user stories, must they be related to use together? Of course not. User stories can exist alone, and epics and features are added just to make requirements management more three-dimensional.
Finally, in Worktile Agile, the requirements are managed in this way. If you happen to need such a management tool for agile research and development, you may wish to check it out.
Author: Worktile senior systems architect at Sun Jingyun
Worktile official website: worktile.com
The article was first published in the " Worktile Official Blog ". Please indicate the source when reprinting.