Shulou(Shulou.com)06/03 Report--

problem

How to prioritize? What is the relationship between the priority of a specific story and the priority of version planning?

Analysis.

There are many areas in agile development that need to be prioritized many times, and this article will explore their different application scenarios and their relationships.

It is worth noting that there are numerous "self-similarities" in agile development, such as estimating that people imperceptibly estimate their tasks every year, every month, and even every day; or planning, there are written or unwritten plans every day every year and every month; and release, each story is its own unit, and together with other stories constitute monthly delivery, resulting in months of large version delivery …...

Because of the different granularity of these self-similar activities, you must not think that you only need to do it once, nor do you think that you can do it in one way. Think about what the goal of this activity is and how it can be better achieved in terms of specific activities.

Version prioritization at the solution product roadmap level

This is the highest level of priority, and the predictability of the ranking is about 3 to 5 years; the sequencers are generally senior managers such as product directors; the sorting objects are generally not user stories or even functional modules, but product lines and products.

The sorting idea is roughly as follows: different user groups need different functions > so the product should be developed for the customer base > identify the current most important customer base and plan the next product > even the same customer base needs to provide services step by step > formulate the product version plan according to the customer's business plan or user's consumption habits.

If you are particularly interested in this, please refer to the link at the end of the article.

It should be noted that companies often lack product director positions, or rarely plan for medium-and long-term product planning, so mid-level product managers often need to think about this.

Iterative prioritization within version

This is a medium-level ranking with a predictability of about 6-10 months; it is generally sorted by product directors and product managers; it is sorted at the module and epic story level.

Epic story

Let's start with what an epic story is. Agile development defines epic stories as "relatively large" stories, but does not define their absolute yardstick. Martians believe that "business data" is a good epic story scale, for example, we say: a product (assuming that it is an agile development management tool) should manage the following data, which should be developed first in the half-year development cycle?

User stories, priorities, user story trees. Iterate × × send Sprint Backlog, the iterative plan will. People, roles, permissions... Departments, teams, groups...

We can say, let's plan like this:

First month: user stories, priorities, user story trees.

The second month: send Sprint Backlog, iterative planning meeting, task assignment Assignment.

The third month: personnel, roles, permissions.

The fourth month: departments, teams, groups.

……

Nth month: integrate and release a version

Note that on this scale, we hardly discuss specific operations (for example, for "users", there should be additions, deletions, changes, queries, etc.), but only discuss which business data to operate on, which is very much in line with people's work habits.

This noun nature of business data can be treated as a reasonable epic story.

Module

If you look at the content of each month, you will find that they are more relevant, such as "people, roles, permissions" these three functions, if they are dispersed into different iterations, it is difficult to develop separately.

This kind of strongly related business data can be called "module", and the division is still based on the business.

Although it is difficult to map each Sprint to a module one by one, you should establish the awareness that each iteration should develop one or more modules that are relatively centralized.

Iterative sorting basis

That is, how to decide which module or epic story should be developed first. People routinely develop based on dependencies, but this is not a good habit.

For example, some people think that if the system can't even log in, how to continue to work, so they put "people, roles, permissions" in the first place, and then it is likely to be "departments, teams, groups", so that when everything is ready, user stories and task assignments can be well developed. As a matter of fact, this is very inappropriate.

The first possible problem is that since the business has not yet been developed, it is difficult to say what kind of people, roles, and rights management methods are needed to support the business.

The second problem is even more prominent: when it was completed in the second month, we had not done anything for the business, making it difficult for senior leaders to understand our progress and hesitate to invest and recruit people. because the functions we have completed are very difficult to help him draw a conclusion.

The second problem is particularly prominent in the process of new product research and development. senior executives are anxious to know the competitiveness of the products, and we are taking our time to build the underlying structure.

So the right thing to do is to start with the core business and prioritize.

Without people, roles, and permissions, everyone can manage user stories, priorities, user story trees, etc., without logging in; without departments or teams, you can think that there is only one team, and then support multiple teams in the future.

In short, do the core business first, and then judge the quality of the product.

Ranking of user stories within iterations

This is a specific development-level prioritization method, sorted by agile development user stories; sorted by the product manager (PO); and sorted by "the need for this functionality to be done in this release".

Sort by

It is worth noting that this feature is important, which does not mean that it must be done in this iteration, and it is likely to be developed before the release of the version (of course, the more important it is, the more important it is to be implemented in an earlier iteration). So what sort is it based on?

It is also necessary for this feature to be completed in this version. This sentence seems abstract, but it is clearer to give an example.

Assuming that this iteration does "users, roles, permissions", which user stories should be done first? Note that specific user stories are discussed here, not these three epic stories.

There are probably a few user stories:

Add users, delete users (accidentally write the wrong user name and cannot be modified), edit users (mail), bulk increase users, freeze users (keep records but prohibit login) …...

Add roles, assign roles to users, edit roles (edit their names without modifying their permissions), delete roles.

Add permissions, assign permissions to roles (and then to users through roles), assign permissions to users, delete permissions.

You can see that several actions are almost necessary: add users, bulk add users, freeze users, assign roles to users, and assign permissions to roles.

Others may not be needed, such as adding roles (you can write several common roles first), editing roles (writing dead first and then providing modification functions later), and increasing permissions.

There are a few that can almost be avoided in earlier versions, such as deleting roles, deleting permissions (this is based on the actual situation of the Martian product, the reader's product may be different), although it is better.

MoSCoW

With a general concept, MoSCoW is a concrete method of operation to help us implement. It is an acronym for these words:

Must: this iteration must be done. For example, the "required" functions mentioned earlier.

Should: we should do it, but forget it if we don't have time. For example, the "less needed" features mentioned earlier.

Could: not really, but it's better to have it. For example, the "not in almost earlier versions" feature mentioned earlier.

In this way, everyone knows what to do first in this iteration. However, this is still a little far from what people will really do, and it often requires some technical means, such as writing TODO tasks according to MoSCoW on storyboards with different background story cards, and no W tasks are allowed until M and S are really completed.

It is worth noting that MoSCoW can be thought of as a way of thinking that can handle all self-similar prioritization problems, not necessarily within iterations (although it was originally designed to do so).

Deal with grey areas

"if I really have time, should I do those Could tasks, or should I just do the next iterative Must task?" This is a real problem.

In theory, the task of the next iteration Must is more important than the Could task of this iteration. However, I prefer to focus on one type of function in each iteration, rather than sporadically mixing with the so-called important functions in the future. This can effectively prevent the decline in productivity caused by distraction.

If you don't like this conclusion, you should try streaming development (which will be described in more detail later). The management model needed by stream development is more demanding to people, but it can deal with many of these problems. In fact, the Martians used streaming development, not iterative development.

Is the inheritance relationship between different priorities and handling priority changes because "users" have a higher priority than "departments", so that "increasing users" is higher than "adding departments", and "deleting users" is higher than "adding departments"? (note that it is not "delete department") the result of our own attempt is: not necessarily. Although inheritance relationships generally exist, it is difficult for user stories to cleanly inherit priorities from epic stories, and iterations are difficult to inherit directly from versions. So focus on the actual business instead of trying to find a panacea. In addition, we often find that a function that was originally thought to be less important is still necessary after a few months. In order to deal with this constant problem, we will arrange an iteration on a regular basis, which is called "optimization." Or "reconstruct." Iteration, which includes the ability to deal with omissions, as well as other transactions such as performance optimization. With this iteration, you don't worry too much about occasional priority errors. In addition, there is no need to worry too much about the messy things to be dealt with in this iteration: yes, as mentioned earlier, I tried to do only a few epic stories to ensure concentration, because at the beginning of the version, it is impossible for people to be familiar with all the stories, and too many things at the beginning will make people more confused. But at the end of the release, everything is relatively familiar, and the iteration of divergent content has little impact, but can help people reintegrate and think about different functions as a whole.

The ranking of product roadmap levels is described in detail in this article: http://cheny.blog.51cto.com/3988930/1101465

About MoSCoW: http://cheny.blog.51cto.com/3988930/1100076

About epic stories and user stories: there are a lot of http://blog.csdn.net/column/details/agile.html in it, including the next three issues of online salons.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.