View auto-similarity of agile development from priority sorting

Author: Chen Yong

Source: blog.csdn.net/cheny_com

Self-similarity refers to the similarity between a part of a thing and its larger part or even the whole.

From a big perspective, Agile Development attaches importance to customer value and advocates continuous delivery. However, in general, the product owner often has a very good sense of customer value, while the first-line developers pay more attention to the technology itself, so once they only stay at the ideological level, in actual work, we will find some deviations. Therefore, we should look at the overall idea and local practice of agile development from the perspective of self-similarity, so that everything is consistent with the idea of agile development.

This article only analyzes the self-similarity of agile development from the agile development idea of "Priority sorting.

"Priority sorting? Is it what the product owner has to do before the schedule ?" Yes, no.

 

Sort product backlog

The purpose of this sort is to find out which requirements are most important and thus may be developed in the last one or two iterations. Generally, the number of entries involved in sorting is close to half a year's development workload, but most of them only have one short name, and only the highest priority needs will be truly refined, that is, the list of requirements to be developed in the last iteration or two. In fact, this requirement list has a special name: willing list, "orders table ".

Why use the tables as a buffer instead of directly forming the sprint backlog of the next sprint? Because the estimation is rough before the plan, in fact, there is no way to accurately list the entries of the next sprint workload; and the product owner should have a detailed or at least in-depth understanding of the development items of more than one sprint, in order to make the development of this sprint have a certain degree of foresight.

Sort willing list

This process is carried out at the Planning Meeting. It can also be said that the process selects the items to be developed in this sprint based on the "Priority", that is, the sprint backlog. It is not easy to complete this selection, because if you just stare at the sorting basis of "importance", it is very likely to pick out the most important requirements from many functional modules, these requirements are combined to form only one unique version. Therefore, you can often select multiple entries in the most important functional modules to form a complete "story group, each has a relatively cohesive target.

To prevent people from moving halfway, we often give each sprint a brief name, for example, "This iteration will release a version with an electronic project list ."

Sorting of sprint backlogs

Are sprint backlogs also sorted? Yes. Is there a situation where an important entry is missed every time? When the sprint is over, do you find that a lot of entries have already started but are not completed? Does the product owner want to use an important change to replace some entries in the original sprint backlog and find that these entries are "under development? Is there a team dispute that all entries should be completed each time (which is really difficult) or only the most important items must be completed? This is because there is no sorting result for the sprint backlog.

Generally, the Moscow method is used in the iteration plan for this sort. Must: required; shoud: should be done; cocould: can be done; wocould not: do not. We need to follow these steps to ensure that the must and shold required by the product owner can be completed, and strive to ensure that the cocould can be completed. In the case of important changes, we should sacrifice the cocould and even the shocould to ensure the change.

Sort story Wall

Are tasks on the story wall and sorted? Yes. Generally, the story Wall follows the columns to be developed, under development, to be tested, under test, and completed. However, it is easy to see that more and more stories are being developed and tested, but rarely completed. This is because the Moscow method is virtual and has not been fully executed. An important feature of the story board is to monitor the number of stories in Development (which I just heard about a year ago). Therefore, the column "in development" is generally the narrower, only a few entries can be put down to prevent various problems raised at the beginning of the previous section.

In addition, the story in the "to be developed" column is generally discharged at three levels: M, S, and C (W won't actually appear). Take m first, and finally change C. If you like, you can use three colors of paper.

Sorting version

What else? Yes, in fact, the largest sorting level is missing at the beginning: if the product development lifecycle is long, what should each version contain in sequence? The best answer is: plan the version content according to the business pace, that is, after each version is released, it must meet certain requirements, obtain some customers, defeat some opponents, replace some products ......

If the product can quickly obtain good market feedback and withdraw funds, senior leaders will usually invest money in the project immediately. Anyway, they will struggle between pushing forward and giving up the project. Many project managers eagerly hope that the leaders will pay attention to and invest in their own projects, but they do not know that their fate is actually in their own hands!

 

The details of the content mentioned in this article can be found in the blog category "Agile development.

 

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