Updated on 2023-11-28 GMT+08:00

Mind Maps

This section describes the work items and common operations for mind map planning.

Multiple mind maps can be created for a Scrum project and can be deleted.

Work Items

A mind map is used to plan and break down the Scrum project requirements. It visually displays the hierarchical structure of work items. When new work items are created during the planning, they will be automatically displayed on the Work Items page.

  • Created work items are synchronized to the relevant epic on the Work Items page.
  • Requirements are planned along the descending hierarchy of epics > features > stories > tasks. You can create an epic, add features to the epic, add stories to each feature, and add tasks to each story.

For fast core functions roll-out and feedback collection, set the priority to High for the stories that deliver the most user values under each feature.

Ensure that the basic functions of a product can be launched and avoid over-engineering.

Table 1 Work item description

Type

Description

Example

Epics

  • The key strategies of an enterprise, such as the major business direction or technical evolution.

    By discovering, defining, investing in, managing, and implementing epics, enterprises can realize their strategies and gain market shares and returns.

  • Since an epic is a high-level description of a requirement, it needs to be broken down into features, which are further divided into user stories in the development practice.
  • It usually takes several months, or multiple sprints to deliver an epic.

    Epics should be visible to all developers so that they can understand the strategic meaning and values of the delivered stories in a bigger picture.

An epic is defined based on an enterprise's operations, competitiveness, and market environment. Examples are as follows:
  • Example 1

    Market differentiation: deliver better user experience than competitors.

  • Example 2

    Better solution: develop a solution for the industrial Internet.

  • Example 3

    Revenue growth: increase paid users by 1 million in the next fiscal quarter.

  • Example 4

    Major technical direction: deploy all products on containers.

Features

  • A feature is a product function that can deliver benefits to customers.
  • Features are broken down from epics and into stories.

    Features are more specific and intuitive than epics, and are often included in the release notes distributed to customers during product release.

  • It usually takes several weeks, or several sprints to deliver a feature.

The description of a feature should specify its values for customers, product form, and delivery mode.

It is recommended that you define a feature in this template: As a <user_role>... I want <result>... So that <purposes>. Examples are as follows:
  • Example 1

    User A wants to import and export data, so that they can efficiently organize data in batches.

  • Example 2

    User B wants to receive notifications of due tasks, so that they can handle the tasks in time.

  • Example 3

    User C wants to have a better drag-and-drop experience, so that they can perform operations more quickly.

  • Example 4

    User D wants to create a nickname for myself, so that they can be more easily identified and remembered.

User Stories

  • Stories further break down a feature and describe requirements in detail from the perspective of users.

    Stories are listed by priority in a dynamic backlog where the order is continuously adjusted to actual requirements. The higher the stories are located in the backlog, the sooner they will be developed and delivered to customers.

    A story must comply with the INVEST principle:
    • Independent: Each user story should be independent and can be delivered to customers independently.
    • Negotiable: A specific description of functions is not required. The details should be negotiated and determined by developers and customers during development.
    • Valuable: A story must deliver values to customers.
    • Estimable: Workload can be estimated.
    • Small: A story should be small enough to be completed in a sprint.
    • Testable: Acceptance criteria should be established to test if a story can fulfill the requirements of customers.
  • A story should be delivered in days within a sprint.
  • You can estimate the workload of stories by person-hours, person-days, or story points.
    • Story point estimation is used by many agile development teams.

      This method estimates the costs for story delivery, including the efforts, complexities, and risks.

    • The Fibonacci series (1, 2, 3, 5, 8...) is commonly used to size a story in a relative manner.

      For example, the workload of a story with 3 story points is three times as large as that of a story with 1 story point.

    • Story points are measured by the Fibonacci series by default.

Examples of stories in compliance with INVEST:

Recommended template: As a <user role>... I want < results >... So that < purposes >.
  • Example 1

    As a project manager, I want to filter requirements by handler, so that I can quickly locate a specific requirement.

  • Example 2

    As a developer, I want to collapse some information, so that visual distraction can be reduced.

  • Example 3

    As a tester, I want to associate test cases with requirements, so that I can track the verification of requirements.

Tasks

In a sprint planning meeting, stories scheduled in a sprint are assigned to members and are broken down into one or more tasks. The expected person-hours of tasks are specified.

Tasks focus on series of actions that lead to a goal. Examples are as follows:

  • Example 1

    Developer A needs to prepare a production-like environment today.

  • Example 2

    Developer B needs to complete the permission settings for the project team this week.

  • Example 3

    Developer C needs to review the code.

Bugs

  • Bugs are created to track problems of software functions found during testing and verification. Bugs can be prioritized.
  • Bugs can be created and tracked separately.

    You can also create bugs when verifying a story. In this case, bugs are set as child work items of the story for you to view bugs by story.

  • The bug description should be as detailed as possible, including but not limited to:
    • Symptoms. You are advised to describe symptoms from the perspective of users.
    • Error code. Error code can be used to locate and analyze code problems.
    • Environment information, such as the development environment, test environment, or live network environment.
    • Software stack information, including the corresponding operating system and its version, and database and its version.
    • Whether the bug can be reproduced and how.
NOTE:
  • Bugs are not displayed in mind maps. They are displayed only in associated stories.
  • Required information for a bug description can be customized by choosing Settings > Project Settings > Bugs.
  • You can configure a bug template or customize fields to ensure team members type necessary information when creating bugs description.

An example template for bug description:

[Symptom]
[Error Code (F12)]
[Environment]
[Fault Reproduction Procedure]
[Onsite Fault Locating R&D Engineer]
[Preliminary Fault Locating]
[Packets Captured Using Google Chrome]

Mind Map

After the requirements are broken down, use a mind map for planning.

  1. Go to the project details page.
  2. Choose Work > Plans > Mind Maps, and click + Create.

    Set the mind map name and click OK to go to the mind map page.

    Table 2 Parameter description

    Parameter

    Description

    Add to Epic

    Selectively add Epic work items that are not in the current mind map of the project.

    Priority

    High, middle, and low priorities are represented by three colors.

    Import

    You can import Excel files from another Scrum project or use a work item template. The template can be downloaded right in the import dialog box.

    Export

    Export all work items to an Excel file.

    +/-

    Click to expand or collapse all the child work items of a work item.

    View details

    Click the title of a work item to view or modify its details.

    Delete a work item and all its child work items.

    Insert a sibling node.

    Remove a work item. This button is available only for epic work items.

    Insert a child node. Click and enter a name to create a child work item. If you want to add more details, click its name and modify on the work item details page displayed.

    NOTE:

    By default, the newly added work items are Assigned To the Creator. You can reassign them on the work item details page.

    Click to import work items to the mind map using a template, or export work items to an Excel file or image.

  3. Add one or more epics, set the names, and press Enter.

    Perform in one of the following ways to add an epic by choosing Work > Plans > Mind Maps:
    • Click for the first addition.
    • Select an existing epic and press Enter.
    • Move the cursor to Requirements and click .

  4. Add one or more features to an epic, set the feature names, and press Enter.

    Perform in one of the following ways to add a feature to an epic:
    • Select an epic and press Insert.
    • Select an existing feature and press Enter.
    • Move the cursor to a feature and click .
    • Move the cursor to an epic and click .

  5. Add one or more stories to a feature, set the story names, and press Enter.

    Perform in one of the following ways to add a story to a feature:

    • Select a feature and press Insert.
    • Select an existing story and press Enter.
    • Move the cursor to a story and click .
    • Move the cursor to a feature and click .

  6. Add one or more tasks to a story, set the task names, and press Enter.

    • Select an existing story and press Insert.
    • Select an existing task and press Enter.
    • Hover over an existing task and press .

Example

Table 3 shows an example of the requirements planning for a mall.

Table 3 Requirements planning example

Epic

Feature

Story

Task

Mall management

Membership management

Administrators can manage the bonus points.

  • Service logic development of the bonus point function
  • Database design and implementation of the bonus point function
  • Bonus points earning rule design

Administrators can set the membership level.

-

Administrators can perform user analysis.

  • User database structure design

Administrators can manage users.

  • User permission database structure design
  • Management console development
Figure 1 Requirements planning example

Adjusting a Mind Map

You can use mind maps to sort work items and adjust their hierarchical relationship.

  1. Sort work items at the same level:

    Select a work item in the mind map. Hold down the left click button and drag it up or down to change its order.

    For example, drag Story_04 to the top of Story_02. When a gray board is displayed above Story_02 with a plus sign (+), release the mouse.

  2. Adjust the hierarchical relationship:

    Select a work item in the mind map. Hold down the left click button and drag it leftwards or rightwards to adjust its hierarchical level.

    For example, drag Story_01 to the back of Feature_03. When a gray boarder appears to the right of Feature_03 with a plus sign (+), release the mouse.

Modifying a Mind Map

  1. On the Work > Plans page, hover over the target mind map, and click to edit the chart name.
  2. Click a mind map to go to the details page.
  3. Add an Epic.

    1. Click . The Add to Existing Epic dialog box is displayed.

      View epics that are not in the current mind map of the project.

    2. Select desired epics and click OK.

      Complete the adding. The added epics and their child work items are displayed in the mind map.

Deleting a Mind Map

  1. On the Work > Plans page, hover over the target mind map, and click .

  2. Click Delete to delete the mind map.

    • Deleted mind maps cannot be recovered. Exercise caution when performing this operation.
    • Adjusting the work item level will automatically change the type of the involved work items.
    • Work items with child work items cannot be adjusted to the Task level.
    • A work item (including its child work items) can be adjusted upwards or downwards in the hierarchy. If the adjusted work item level exceeds the task level, the work item cannot be adjusted.
    • The planned work items will be displayed on the Work > Work Items page.

      You can filter work items by epic, feature, and story.