In this paper, youzan retail products will be taken as an example to introduce the management practices of the whole life cycle of demand, including: original demand collection of merchants, product design and review, demand realization of RESEARCH and development, operational feedback after launch, and a new round of iterative optimization, which constitute the feedback loop of the whole life cycle of demand.

How did we effectively organize and manage requirements, projects, tasks, defects, online quality, and functional optimizations throughout the process? Let’s unveil this mystery together!

“1 item +3 Kanban” model

In order to make the product and development process more controllable, to make the collaboration between each other more smooth, and to make the results of joint efforts more reliable, we designed the “1 project +3 Kanban” model.

“1 project” means only 1 JIRA project used by Yizan Retail Division to manage product requirements, technical requirements, technical tasks and test bugs), and “3 Kanban” means:

  • “Likeable retail Product Demand Board” for product managers;
  • A “positive retail project Kanban” for the R&D process;
  • “Positive Retail Bug Kanban” for the beta phase

The “Good Retail Project Kanban Board” is the Scrum Board, and the other two Kanban boards are implemented through different JIRA filters. Since we need to split, estimate, and iteration planning of product and technical requirements, the “Likeable Retail Project Kanban” is designed as a Scrum Board, which provides two views: The active Sprint view of the kanban allows us to view requirements and technical tasks for all Sprints currently in progress (both project iterations and daily iterations), as well as a single Sprint view. Before formally entering the “1+3 model”, let’s start from the source of demand and introduce the management method of original demand of merchants.

Business original demand management

The demand feedback from the business mainly comes from the full, business service, channel sales, user research classmates and BBS demand posts. BBS demand posts are dealt with and fed back by the product students on a regular basis, while the demand from other sources will be uniformly submitted to the common JIRA kanban “Customer Service Demand Feedback/Synchronous Kanban”.

The kanban provides multiple perspectives on the needs of each product line, as well as dedicated swimlanes for “user experience issues” and “major customer needs.” Each requirement card shows its product name, pre-processing results, and expected release date. The demand feedback from the business is the original demand, which cannot be directly used in production. The product manager will follow up and deal with it. Therefore, technical students are not required to intervene in the kanban.

The benefits of choosing the JIRA Kanban tool for administration are:

  1. Search to see if similar requirements have been submitted to reduce duplicate submission of requirements from different sources;
  2. Capture each process that requirements go through;
  3. Email notification mechanism, the update of requirement card (such as: remarks, status update, etc.) will be notified to the stakeholders of the requirement by email, such as the reporter and the concerned person.

The product manager filters out requirements that are relevant to him or her and preprocesses them if they are newly submitted:

  1. To judge the requirements that are of low value or definitely will not be done, drag the requirement card directly to the “Completed” column, select the solution result “will not be repaired”, and note the reason;
  2. To determine the requirements that have some value or need to be reanalyzed, drag the requirements card to the “Product Requirements Pool” column. In the popup window, select “Preprocessing Result” as needing to be reanalyzed, can be started soon, or has been planned into the project.

We will present various statistical results in the form of reports for management decisions, such as: pre-processing results of requirements in the “Product Requirements Pool” column and demand cumulative flow diagrams for different product lines. Next, we introduce the demand management method in the “Planned project”, which comes from the “customer service demand feedback/synchronous kanban” and is managed by “Story” type in the product demand kanban of each business division in the granularity of “function” after design by product students.

Product demand Management

The product manager will use the product PRD documentation to export requirements to r&d students. The standard product PRD templates are available in the fluence where “create” is located. Found. This template includes: the basic information of the demand (the author, the source of priority, and the expected launch time), demand background, introduction, objectives, overall demand (feature lists, business processes and business rules), prototype and visual draft, detailed requirements (a detailed description of each function), data requirements, other instructions and risk.

“General requirements → Function list” will list all product function points involved in requirements. This demand management method of “splitting big requirements into successful points” is called requirement itemization. The itemized feature list allows requirement stakeholders to briefly understand the features to be done, while the fine-grained feature list facilitates the management of requirements during the development phase.

We use JIRA to manage the list of product features, and requirements can be divided into two categories based on size: a) Epic requirements, large requirements or product features using JIRA problem type Epic (Epic); B) Stories are used for product feature points, user stories, or daily requirements, which use the following unified JIRA workflow. This workflow may seem a bit complex, but it consists of two main phases: a) Production phase: Demand pool [Open] → In the process of [product-in Design] → In Review] → Waiting for [product-waiting for Development] ···> … > development “In Progress” – has been completed In the Resolved | Closed 】.

To make the process management of requirements more intuitive, we use the Product Requirements Kanban to manage the feature Story (as shown below). A Story can represent either a feature in the product PRD or an online feature to be optimized. The former is planned for completion in a project, while the latter is planned for completion in a daily requirements week iteration.

Since Youzan retail products contain multiple lines of business, we use JIRA “modules” to distinguish stories from different lines of business. Stories across multiple lines of business need to be marked as multiple modules, and the requirements of only this module can be viewed through the “Business Module Quick filter”. Each Story card on the requirements Kanban displays the description of the Story, the name of the epic to which it belongs, and the name of the planned release.

We usually batch create product feature point stories directly from PRD documents into product requirements kanban by: Clicking a feature name three times in the feature list will bring up two “shortcut menus”, The menu on the right is “Create JIRA Issue” (as shown below) → click “Create JIRA Issue” and enter the “Create Issue” pop-up box → select “Create multiple issues from table” → select the corresponding project and issue type: Story → Select “Summary” (JIRA theme) as follows: In the “Name” column of the feature list, the description (JIRA description) is as follows: In the “Description” column of the feature list, click “Create” to complete the batch creation of product requirements from PRD documents to JIRA.

Insert “JIRA link and status” on the right side of each function name. Any update of Story status will be updated synchronously in product PRD in the future, and product PRD link will also be automatically added in JIRA to realize data exchange between JIRA and Confluence. We will display these two Stories in the “Demand Pool” column of “Liked Retail Product Demand Kanban”.

At the end of each month, a monthly planning meeting is held, which is mainly attended by the product and technical leaders of each product line, in order to agree on the priority of the requirements that need to be done in the next month.

When the PRODUCT PRD document passes the internal scheme review of the product, the product manager will explain the product requirements to the R&D students. After the UI design and interaction draft are completed, the designer will also conduct a UI design review for the product manager and front-end students to ensure the effectiveness and integrity of the information delivered and avoid unnecessary communication waste in the later stage.

Technical requirements Management

Technical transformation requirements, such as CONVERTING PHP to Java, will not affect the functions of online products, which we refer to as “technical requirements”. In order to distinguish it from functional requirement Story, JIRA problem type Feature is used to represent technical requirement (note: Feature is officially defined as a product Feature and also belongs to functional requirement). The workflow is simple: To Do [To Do] | – Reopened 】 【 underway (development/test) In Progress – > completed Resolved 】 【 】 | [Closed] (hang “On Hold” temporarily didn’t use), as shown In the figure below:

In order to simplify the use posture of r & D students, the management of Technical requirements and product requirements use the same data storage structure, namely: Epic → Feature → Technical Task (product requirements: Epic → Story → Technical Task). The created technical requirements Feature is displayed directly in the Scrum Board Backlog, while the created product requirements Story must be in the development phase (i.e., the state to be developed or after) before it is displayed in the Backlog.

In the system analysis stage, we will use a unified technical scheme template for technical review, including dependency analysis between different systems, business process analysis and system interface agreement, etc.

Technical Task Management

Technical task, similar to the workflow technology requirements of the workflow from product requirements (including products daily requirements), or technical requirements (including technical optimization) will be broken up into before development can be assigned to a single research students perform technical tasks, and each task of the original estimate time about 8 h (up to no more than 16 h), The types of technical tasks include front-end, back-end, data, Android, iOS, applets, development self-testing, use case writing, and use case execution.

So far, we have formed a three-tier model of requirements separation, namely: Epic-> Feature Story/ Technical requirements Feature → Technical Task. Product managers only need to pay attention to the business requirement Story, while r&d students need to pay attention to the technical requirement Feature in addition to the Story. We configured the Backlog card layout to show three extended fields: σ original estimated time, σ progress, and due date, making it easy to see the estimated amount of work required, current completion progress, and completion date, as shown in the project Kanban Backlog in the figure below.

After the iteration Sprint is started, we can track the execution of technical tasks in the “active Sprint” of the project Kanban. Common operations include: a) dragging the task card to update the status; B) Add a Flag to the blocked task card (right click on the card → add Flag) to remind project members. Delete the label after the risk is removed; C) Assign the task card to yourself, select the card, and then click the “I” key on the keyboard; D) Log work daily or when dragging tasks to the “Done” column.

We use Sprint burn charts and periodic stations to assess and identify the overall progress of the Sprint. In practice, we need to know how much progress everyone is making in that Sprint. To meet this requirement, a report of Sprint Task Completion by Assignee is designed, showing each individual’s original estimated time, actual time spent, Task Completion rate, and time consumption rate.

At the end of the Sprint, we will use the “starfish chart”, “KISS” or “good/should do better” method to recheck. The improvement measures of the recheck will be recorded in the “Like Retail Recheck Action Follow-up Kanban”. Each Action must be a specific Action that can be implemented. There is a principal (JIRA manager) and a completion date (JIRA due date).

Test Bug Management

Bugs found during the iterative Sprint testing phase are submitted to the “Bug Kanban” with a workflow similar to that of technical requirements/tasks. However, the column names for the Bug kanban are quite different from those for the active sprint Kanban, with the addition of ‘Resolved’ and ‘On Hold’. When a Bug does not need to be fixed for the time being, we can drag it to the “pending” column and specify the reason for the pending in the JIRA notes.

The popup window for submitting test bugs prompts the reporter to fill in the “standard Bug description template” (including resteps, actual results, expected results, and captured data). In addition, the test Bug must be associated with the JIRA module, the affected version, and the resolved version. This way, after we associate stories, features, and bugs to the JIRA version, we can view the released, unreleased, and archived version information by “version” in the released version. We can count the remaining test Bug stock distribution in a certain version according to “module” and “handler”, as shown in the following figure:

Online problem and fault management

Not only do we manage test bugs during development, but we also manage issues and failures during the operational phase after requirements go live. Online problems are generally defects, tasks and queries that have little impact on business, while online faults refer to the unavailability of all or part of the IT services provided to customers, including the degradation of service performance (for details, see “Favorcoder” technical blog “Favorcoder Online Fault Management Practice” published in November 2016).

Since the two have different severity and impact levels, we use different processes for management. The current online problem handling process is shown in the following figure, and JIRA Kanban is used to assist the process management (the red color in the process indicates the JIRA status). In order to follow up online problems, we will publish “Online problems Daily” in the product and R&D group every day, showing the stock of problems of each business team and the duration of these problems in the form of statements.

Online functional improvement iteration

After the launch of the new function, businesses will feed back to us the problems and suggestions they meet during the use of the function, such as suggestions for improvement of the function or relevant new requirements. These requirements will be submitted to the “Customer Service Requirements Feedback/Synchronous Kanban”, valuable small requirements will be quickly fed back to the customer within each business unit in a daily iterative way, while valuable new requirements will be handled on a project basis. No matter which way is adopted, Youzan Retail Business Division will manage in the retail product requirements kanban in the form of function Story. After the product scheme design is completed and passed the review, it will enter the r&d stage, and then manage the whole R&D process by JIRA iterative Sprint.

Daily Requirements week Iteration Sprints are fixed, starting on Friday and ending on Thursday evening (as shown below), with outstanding product or technical requirements moved to the Backlog or the next Sprint. The cycle of sprints managed by project is not fixed, and the sprints end when the project is scheduled, and there may be delays.

Some business units or product lines use an independent business unit daily demand pool (JIRA Kanban Board) to manage daily demand. The product leader will regularly bring the product manager of the demand side together with relevant R&D students to prioritize the demand list and select the most valuable demand as the target of the next stage. This can improve the cooperation between upstream and downstream.

Difficulties encountered and countermeasures

The implementation of any new process will encounter many obstacles. Since the JIRA system was introduced into the Youzan retail project in the second half of 2016, I have been trying to guide everyone to follow the standard process, but it is not appropriate to force them to follow. For example, for the registration of actual time spent, we can only rely on frequent reminders in the task follow-up process. After collecting some project process data, I will use EazyBI tool to make various data reports. When people have a sense of the data reports, they will improve their cooperation in process execution. For example: Counting the number of test bugs for a Sprint and publicly synchronizing this report frequently can be an effective way to encourage developers to update their JIRA status.

In addition, we can also use the force of “downstream pull upstream” to promote the landing of the process, such as: In the test Bug kanban, only when the developer fixes the Bug and updates the JIRA status as Resolved can it be in the “Testing” column. Then the tester will continue to check whether the Bug has been fixed. The tester will also remind the developer to update the Bug status in time, otherwise they will not accept the test. It’s important to remember that no process or tool is perfect and that it fits in the moment. As business requirements change and team size expands, these processes need to evolve with The Times, and suggestions for improvements that “emerge” from the team may make the process more relevant to the business and team needs, making it cheaper to manage.

summary

“Demand lifecycle management” is a very big topic, this paper only introduces some practice methods of Uzan retail products:

  1. Use a unified kanban to manage original merchant requirements from different feedback channels;
  2. Use “1+3” model to manage product requirements itemization and r&d process;
  3. Use online problem and failure process to manage online operation quality after requirements are issued;
  4. Use daily requirements Kanban to quickly iterate on business feedback for feature optimization suggestions.

However, we still have a lot to improve:

  1. Lack of market demand analysis (output: MRD document) from “demand collection” to “product design”, and insufficient value assessment of demand in the early stage;
  2. There is insufficient information synchronization or training on market, full capacity and serving students before demand release, which reduces the service response level;
  3. The online operation data analysis after the release of requirements is not enough to effectively evaluate the ROI of requirements;
  4. Good business agility still has room to improve, with only around 40% of requests currently released within a month.

In addition, JIRA cannot meet the operation demands of the whole company for project sets or projects. While using JIRA and Confluence system, we are also independently developing “Favorable efficiency Platform”, which has good support for monthly demand planning meeting and project management.

The platform’s vision is to empower teams to manage the “product lifecycle” and increase productivity by enabling team collaboration. In 2018, Youzan has raised the “demand life cycle” to the strategic height of the company, and the “R&D efficiency” team I am in still needs more excellent partners to join.

Finally, I would like to thank Tian Ying, Li Bin, Qin Yang, Bai Yueyue, Lian Hengrui and Cui for their support and review of this article.

Remark:

  1. JIRA Feature is used to refer to “technical requirements” as opposed to product requirements. What it really means is: product features, granularity larger than Story, granularity smaller than Epic;
  2. JIRA Sprint (Sprint) is used to represent: an independent project, multiple iterations of a large project, or a weekly iteration of daily requirements, etc. In order to achieve a Sprint goal, stories and features related to this goal are planned into a Sprint.
  3. JIRA Version is used to represent: From the perspective of product roadmap, a requirement release, each release contains one or more new product features or functional optimizations and technical optimizations. It is not directly related to the JIRA Sprint, but the requirements in one Version may be completed in multiple different Sprints.
  4. In general, we refer to the JIRA Scrum Board as Agile Kanban and the JIRA Kanban Board as general Kanban (no “planning” features);
  5. Each column of the JIRA Kanban corresponds to one to more JIRA states, and each column can be configured with WIP, which is currently used by very few teams;