Understanding the Four Keywords of Agile Requirement Management

Background

What is the relationship between concepts related to agile development, such as epic, feature, story, and task? How can we flexibly use these concepts to make agile requirement management more efficient? This section analyzes these four keywords in detail.

What Are Epic, Feature, Story, and Task?

Epic, Feature, Story, and Task indicate requirement granularities in descending order, which are used to divide requirements. They can be regarded as requirement placeholders. Their meanings can be used as a reference for requirement division.

• Epic: project vision and goal. It holds significant strategic value for an enterprise, because its implementation, usually lasting several months, brings about the corresponding market position and returns.
• Feature: a product function or feature that delivers benefits. Features are more specific and intuitive than epics in customers experience, possessing business value. It usually takes weeks to complete sprints.
• Story: a user story. A story is a user's detailed description of product functions. It puts features into a product backlog for continuous planning and adjustment. Stories with high priorities are prioritized for delivery and hold significant user value. Stories must comply with the INVEST principle (Independent, Negotiable, Valuable, Estimable, Small, and Testable). It takes several days to complete stories, usually in a sprint.
• Task: a specific task to be completed by team members. At the Sprint planning meeting, stories are assigned to members, and members break down the stories into tasks and estimate the workload. The whole process is usually completed within one day.

What Is the Relationship Between Epic, Feature, Story, and Task?

Epic-Feature-Story-Task manages requirements in a structured manner. It breaks down requirements layer by layer to build bottom-up dependencies, as shown in Figure 1.

How Can We Flexibly Use These Concepts to Make Requirement Management More Efficient?

This section splits and displays the requirements of a case based on CodeArts Req to provide a detailed description of epic, feature, story, and task.

Case:

The turnover of a large store dropped sharply due to the impact of the Internet.

To keep its consumers and maintain the market position and share, the market decides to build its own online store in six months.

• Step 1: Determine and create an epic.

  As described above, granularity and meaning must be taken into consideration before requirement confirmation.

  Is a product an epic? Is each service module of a product an epic or feature? These questions need to be answered.

  • A product is usually of strategic significance. Therefore, it is suitable to take a product as an epic. However, it does not apply to all products. The product itself and its granularity matter. In this case, the online store cycle is 6 months, and the goal is to maintain market share. In view of granularity and strategic sense, it is suitable to take the online store as an epic.
  • Whether each service module is an epic or feature depends on the actual situation. For example, building a smart city is a vision, which includes large service modules, such as smart transportation, smart government, and smart community. Therefore, it is better to use epic as a placeholder.

    Create a Scrum project in CodeArts and name it "Large online store". On the page for requirement planning page, create an epic.

    Figure 2 Creating an epic
    

  After the creation, click the store to go to the editing page. Fill in the description. You can use the template provided by CodeArts.

  • As: As for this epic, the user is the entire company.
  • I want: The desired result is to build an online store.
  • So that: The goal is to keep consumers and maintain market position and share.

    Set the start time, end time, priority, importance, and estimated workload of this epic. The information is essential to understanding the product and project. Therefore, you need to fill in the information in detail.

    Figure 3 Writing an epic
    
• Step 2: Break down the epic into features.

  The customer requires that five functional modules (promotion management, member management, order management, delivery management, and client) be delivered within six months. A team sprint is two weeks. Each module requires two or three sprints. In view of granularity and meaning, it is suitable to take five modules as features.

  Figure 4 Splitting the epic into features
  

  After the creation, you can edit the information on the details page. The information items on the page are the same as those on the epic page.

• Step 3: Break down features into stories.

  Agile development is gradually detailed. It is not required that all requirements be detailed at the same time. Only the stories of the current sprint and one or two future sprints should be detailed. The story of a future sprint can be general. Stories in the current Sprint must comply with the INVEST principle. The development team needs to complete delivery at the end of the Sprint.

  Member management, as a feature, has a higher customer priority. Therefore, member management needs to be broken down into stories and added to the product backlog in the requirement review. After the breakdown, the following functions related to the administrator need to be included: bonus point management, member level management, user analysis, and user management. These specific functions can be taken as stories. Note that it is better to deliver stories in a sprint. If the delivery fails, further break down the stories. Only delivered stories are valuable. Stories that cannot be delivered are a waste for the current Sprint. The stories after the breakdown are shown in Figure 5.

  Figure 5 Breaking down features into stories
  
• Step 4: Break down stories into tasks

  At the Sprint planning meeting, the team and PO need to jointly select the stories to be completed in the Sprint from the product backlog according to the priority and put them into the sprint backlog. After claiming the story, team members break down the story into tasks for further estimation.

  So how can we distinguish stories from tasks?

  • Story focuses on value and needs to be completed in a sprint. The completion must comply with the INVEST principle and usually takes several days. Story is more of a noun. For example, bonus point management as a story can be described as follows: As an administrator, I can manage bonus points of members to provide different value-added services based on consumption levels.
  • Task focuses on value realization. Story functions are implemented based on tasks. Task completion usually takes 1 to 8 hours. Task is more of an action. For example, bonus point management as a story needs to be implemented through service logic development, bonus point rule design, and bonus point database design. These are tasks, as shown in Figure 6.
    Figure 6 Breaking down stories into tasks
    

  In this way, the online store requirements are broken down into epics, features, stories, and tasks.

Summary

When using "Epic-Feature-Story-Task" to manage requirements, pay attention to the following aspects:

1. In agile development, requirements are gradually refined and broken down in a top-down manner.
2. Epics and features are large-granularity requirements. They are users' expectations for products and descriptions of functions and features.
3. You need to break down features into smaller stories. Future requirements (possibly in three or more sprints) do not need to be further divided. In some sprints, break down stories into smaller ones.
4. In a sprint, stories are broken down into tasks.
5. All the rough and detailed stories are placed in the product backlog. The entire list must be detailed appropriately, emergent, estimated, and prioritized (DEEP). The list must be sorted out and prioritized periodically to ensure that high-priority requirements are implemented and delivered first.
6. Keep contact with the customer during the whole process to ensure that the functions to be implemented are what the customer really wants.