How can product managers manage requirements effectively?

Requirements are the single most important input in an entire software project. The biggest difference between software development and traditional production industries is that requirements are always vague, subjective, and constantly changing. Compared with the physical hardware requirements of electronic products, automobiles and other manufacturing industries, the description and acceptance of software development requirements is a difficult problem to solve.

However, requirements are the decisive factor for the success of the entire project, so we must manage requirements so that they become the baseline of the entire software engineering. So that all products, design, research and development, testing, operation and maintenance work can be carried out around the unified requirements. To ensure the smooth progress of the project and achieve the objectives.

Difficulties in requirements management?

In general, requirements are difficult to manage for the following reasons:

1. Problem of requirement description

In general, the easiest way to create a product that doesn’t function as it was designed to do is to describe the requirements. In most cases, the person writing the requirements document is not wrong, and the person reading the document is not wrong. Sharing documents is not the same as reaching consensus. It’s just that people have different understandings of the same description, and it’s bound to happen. Therefore, the requirements must be discussed face to face with the team to ensure a consistent understanding of the requirements.

2. The problem of changing demand

There are many reasons for demand change, such as not identifying the whole at the beginning, new demand; Business changes lead to changes in requirements; Wrong requirements; Requirements are not clear, etc. Changing requirements can lead to changes in everything from design solutions to coding tests, delays in delivery, and complications. This requires the team to make the requirements as clear as possible before the iteration begins.

3. Priority and scheduling of requirements

The most important question in requirements management is what features provide the most value to users. Because in software development, you always want to develop more features than you can put resources into. Therefore, finding the most valuable features in this section, prioritizing them, and delivering them as early as possible is the core of requirements management.

How to manage requirements hierarchically?

User stories are widely used in agile development, but I don’t think they are enough to manage an entire project. (Not to mention the many benefits of user stories.) User stories can describe really valuable requirements and also provide priority and story point size as a basis for scheduling. But with so many peer user stories, you can get lost and miss the forest for the trees. Every delivery and release turns into a patchwork of features, sometimes deviating from the overall product vision for the value of a single feature.

Therefore, we recommend managing requirements in a hierarchical order of Epic Story-feature-user Story. The team can also have its own hierarchy definition, depending on the team’s preference.

The advantage of hierarchical requirements according to Epic story-feature-user Story is that Epic level can be aligned with product strategy, Feature level can be used as the object of release planning, and User Story can be developed iteratively.

1. Epic Story

An Epic Story is an Epic Story. A generic epic is defined as a very large user story, a backbone task in a product or a company-level strategic initiative, typically lasting several months. We evaluate the risk, business value and workload of the epic, and get the priority of the epic, and then schedule the epic according to the priority.

2. Feature

A Feature is a complete Feature that provides value to users. Describes a complete feature that a product has. Features are typically large, lasting several weeks and spanning several iterations. Generally used as the planning object of the release plan. We prioritize features based on their risk, business value, and workload, and plan for release.

3.User Story

A User Story is a User Story, and a User Story is a functional scenario that provides value to the User. In general, features can be broken down into multiple user stories, each of which is valuable to the user, but individual stories may not be properly used by the user or may be a segmentation of the overall functionality. We estimate the story points of the user story and develop them in an iteration plan.

How do we manage requirements at Worktile?

I. Demand collection

There are four main sources of demand for Worktile:

• User feedback to line of business colleagues.
• Requests from colleagues within the company.
• Users directly feedback their needs through the product help center – user voice.
• Requirements planned by product manager.

1. Requirements from the first two sources are all summarized in the unified requirements collection project, which requires the proposer to create in the form of user stories and describe specific user scenarios.

All requirements feedback is created in the form of user stories and evaluated by product managers. The requirements recommendations that are adopted are further analyzed to determine whether they are epic, feature, or user stories based on the size and impact of the story, and are responded to in the requirements planning of the corresponding project.

2. Users can submit their own requirements suggestions in the help center, or give a thumbs-up to the existing requirements suggestions or our plans to improve their ranking in the queue.

For these requirements, the product manager will view them through the background, analyze and evaluate them, and then consider responding to them in the requirement planning of corresponding projects.

Second, demand realization

1. The product manager will plan the overall requirements of the functional framework of the whole product in accordance with the hierarchy of epic-feature-user story in the corresponding project.

Prioritize the planned requirements to determine which features of the ongoing epic need to be released in the next release. Plan it into the corresponding version.

3. Break features into user stories for release, estimate user stories, and plan development according to iteration capacity.

4. User stories that enter the iteration will be delivered according to the iteration cycle, updating the progress of features. Update epic progress after feature acceptance is complete. Push the entire product development schedule from bottom to top.

By managing requirements of different levels in different dimensions, the whole demand management process is clearer and smoother, which greatly improves the efficiency of demand management and focuses on product objectives.