Agile development user Story Series 4: Priority sorting

This is the fourth article in the agile development user story series. (Topic directory)

Priority sorting sounds like a very simple task. A field is almost "important/General ......", Adjust it and sort it.

But there are a lot of names in it: Who should be responsible for sorting? Who made the final shot? Do R & D factors need to be considered? How to deal with the order caused by requirement dependency? Continuous delivery considerations? Business Decision-Making considerations?

The following knowledge and experience come from multiple sources, including some online materials and interviews with actual projects. They are verified in a project they are currently working on. The specific application should be flexible.

Who is responsible for sorting?

The product owner is responsible.

In the product development environment, it is generally the product manager; in the project development environment, it is generally the project manager.

As the manager of a product or project, this person must be familiar with the product or project overview, from business overview to business details. From this point of view, the knowledge level is more than that of the R & D team.

It is not appropriate for some teams to hand over the sorting work to customers.. At any time, the customer only participates in the process in a shallow manner and may be lazy and inattentive at any time. Therefore, do not give the initiative to the customer. Even if the customer is required to handle the issue, the corresponding internal personnel should be responsible for controlling the issue and determining the authenticity of the sorting.

Who is responsible for making a shot?

If you want to understand both the overview and the details, the product manager (which is omitted from the Project Manager) is too demanding. At this time, the product director is usually provided to control the situation at a higher level.

The product director's work tends to be long-term, market-oriented, and humanized. For example, product managers of many consumer electronics products are responsible for researching trendy features, while product directors are responsible for researching "trendy people who use these features ".

R & D considerations

Despite the intent of ranking by customer value, the actual situation is that the technical implementation and dependency of product functions are often restricted and have to be changed.

Therefore, the involvement of the R & D team should be considered.

What? Customers, product managers, product directors, R & D teams ...... Who makes the decision? By the way, it is generally necessary"Product owner team", that is, the Po Team.

The first time I heard this kind of team, I saw the development experience of a foreign game team. Their product owner team has introduced senior executives, planners (demand developers and management personnel), developers, publishers, enthusiastic gamers, etc, the final work is summarized by the main planning (product manager.

Requirements and dependencies

In fact, most demand dependencies can be avoided. For example, there is no "delete function". In the early stages of development, you can log on to the database to directly perform brute force deletion.

But this will bring about future problems, such as continuous delivery. How can this be used by customers? For more in-depth questions, let's continue.

Continuous delivery considerations

When I was training at MPD last time, someone asked the following question: "We have been delivering continuously, but at the beginning our products were short of arms and legs, and the interface was not beautiful, the customer shook his head and was very impressed with us. What should I do?" After being busy for half a day for continuous delivery, it turned out to be counterproductive.

The biggest problem that actually occurs here is:Be sure to understand executable software and continuous delivery from the customer's perspective, rather than from the development perspective!

From the development point of view, on the continuous integration system, there is an EXE or DLL generated every day, it can be run, sustainable delivery, in fact, a big mistake.

For example, an agile development and management software can be run in the first minute. However, it is estimated that the software can be filled out and presented to the user's story in any case until the second week; however, to sell the product at the end, you must have secondary features such as "users and permissions. These so-called "Secondary functions" are provided to the customer before they are implemented, but they are not explained to the customer, which is likely to be counterproductive.

Of course, one way is to put the "login function" in advance, so that it will not be able to be provided to the customer from the first day? No.

Business Decision-Making considerations

As a product, we should always put the function that best reflects differentiated values before everything goes wrong.That is, whether the product is worthwhile or not within three months, and whether the product's main functions and the amount of manpower invested are determined within six months. from nine months to one year, it is released (the time point here is only for example and needs to be mastered flexibly ). ThereforeDo not put the login function above the road, it will accumulate a large amount of manpower and greatly delay decision-making.

For example, a game company has made a lot of basic games that can be logged on, played, traded, and photographed in a platform-based manner in order to know in advance whether the game is fun or not, the new team only needs to make core gameplay on the top to provide high-level judges on whether to continue or not.

The purpose of early value-oriented functions or platform-accelerated development of core functions is to give early decisions.

I have encountered a small number of projects, but obviously I should not start with some roadside functions.

Best Practice: story Group

The so-called story group is the result of observing some teams and their own practices.

The story group is close to the concept of an epic story. After the story is delivered by each story group, the customer can complete some functions and classify several stories into one group, and try to implement a group in each iteration, deliver or present it to the customer.

For example, if you want to develop software in agile mode, you may plan the following groups:

1. User stories

2. Group related to the iteration plan

3. Routine work group

4 .......

These benefits include:

1. After each group is delivered, the local functions are relatively complete and can be fully used by the customer, so as to provide centralized feedback for certain functions.

2. Because these functions are talking about one thing as a whole, the customer and developers are concentrated and can think about one thing thoroughly.

Of course, this method still requires the product manager's ability to work, otherwise it is difficult to smoothly connect between groups.

 

 

Click to download the free agile development textbook: Martian agile development manual