When estimating or planning agile projects, we often mention the following concepts.
- Epic Story
- Feature
- Minimal Marketable Feature (MMF)
- Theme
- User Story
- Task
This article will explain the meaning of these concepts and the relationship between them.
Feature
Feature is something that can provide customers with value. It represents what a product can do or what service it provides; it is a feature that can meet the needs of users, serve customers, and bring real value to users.
Feature is relatively complex and can be expressed by a set of sentences with a verb-object structure. For example, a supermarket transaction can be described as:
- Scan barcode
- Display unit price
- Calculate the total price
- Calculate tax
- Print the list
Therefore, a Feature is difficult to estimate, it needs to be broken down into smaller units, which is the User Story to be discussed below. Feature is generally at the level of Release Plan, and a Feature may take several iterations to complete.
Since Feature is a deliverable that meets the needs of users, the object delivered each time should be one or more features. It can be said that Feature is the "Working software" in the Agile Manifesto.
Minimal Marketable Feature (MMF)
After understanding when Feature, let's discuss MMF again. As the name suggests, MMF is the smallest set of functions that can be marketed. First, it is Feature, and second, it emphasizes the concept of marketization. Marketization means that it can be submitted to users for use, and can get corresponding returns from users. MMF can make investment gains in advance, which is very important and practical for an enterprise.
User Story
It was mentioned in the discussion of Feature that Feature is composed of a set of sentences with verb-object structure. These verb-object sentences describe a User Story. A Feature can be decomposed into multiple User Story, each User Story cannot be used alone, but together constitute a Feature.
A User Story must be clear, can add value to customers, and more importantly, can be estimated. Therefore, User Story is usually the basic unit of estimation, and Story Point is usually used for estimation. User Story is at the level of iteration, and a User Story must be completed within one iteration.
In addition, User Story is also a tool for requirements analysis. By asking who, what, and why, we can capture customer needs in a simple and clear way. Therefore, User Story is usually written in the following form:
As a, I want, so than. For
example,
as a document editor, I want to remind me to save the document when I exit the editor after the document is modified, so that I will not lose data.
User Story has the following six characteristics (INVEST):
- Independent: Independent
- Negotiable: Variable
- Valuable: Valuable
- Estimable: Estimable
- Small: small enough
- Testable: Acceptable/testable.
Because User Story has acceptability features, it is more accurate to use User Story to track development progress. Tasks can also be used to track development progress, but the completion of tasks is sometimes not so easy to clearly define or visualize, while the completion of User Story is visual.
Note that some articles think that User Story is composed of Feature, but in fact this Feature should be Functionality.
Task
The work unit that can be executed in the project is usually the project in the iteration plan (such as the project in the Sprint Backlog). A User Story is generally broken down into one or more Tasks, which are implemented through these Tasks. If the User Story of unit price is displayed, it can be broken down into:
· Design seminar
· Server query unit price code
· Server query unit price test
· Client display unit price code
· Client display unit price test
Of course, a Task may not implement any User Story. Such as: Release plan meeting.
Epic Story
As the name suggests, the scale and complexity of Epic Story are greater than User Story, and it is first of all a big User Story. Because it is very large, it is impossible or difficult to estimate, so it is generally broken down into smaller User Story for estimation and development. Regarding Epic and Feature, there is no unified statement about which is more complex and whose scale is larger. In some projects, Epic Story will be defined under Feature; in some projects, the opposite is true. Therefore, when using this concept, there should be a clear definition in the project. Regardless of whether Epic Story is above or below Feature, it is also at the level of Release Plan like Feature, and is generally completed through one or more iterations.
Theme
Theme is a group of User Story (even Epic Story), these User Story have common characteristics, in order to make it easier to develop these related content, these User Story is usually developed and managed as a group. This group of User Story is called Theme. For example, if the report function includes Excel report, Word report, PDF report, etc., the "report" is a theme.
The relationship between Theme and Epic/Feature can be clearly defined in your own project. It depends on the preferences of the project team members.
Therefore, from a hierarchical level, the relationship between these concepts should be:
Example:
Epic: It can be understood as a large version. 1.0, 2.0, 3.0 and the like, large modules of planning, such as e-commerce self-operated, and then merchants to settle in
Feature: features, such as 1.1, 1.2, 1.3. For example, Alipay is added to the payment, and the login supports scanning codes.
Backlog: What to do, the requirements that have not yet started
Task: On-going requirements
Or:
It is worth noting that the concepts of Epic, Feature, and Theme can be defined in their own projects without necessarily complying with the requirements in this article rule. As long as in your own project, you can clarify their relationship by drawing a relationship diagram similar to the above, and get the approval of each member.
refers:
https://www.yuque.com/jingwhale/blog/vvpxff