project evaluation

Under the traditional project management mode, project evaluation is the focus of project planning stage. After the demand analysis is split, the number of people required for each module is calculated according to experience, and the time and number of people required for the project are calculated after balancing the three musketeers-time, quality and cost. The project library manager takes the lead and evaluates with technical experts.

Under the agile framework, the evaluation will be carried out more frequently. At the beginning of each iteration, the estimation method is no longer the number of people but the number of stories, and the estimator is no longer the project manager, but the entire scrum team.

How to estimate under agile framework? What kind of confusion does the average team have in the estimation process? What kind of trap will you fall into?

Scrum is estimated according to the difficulty of user stories, and usually the following indicators are selected for estimation.

Fibonacci series is commonly used, which is estimated by the number of 1- 13, because some studies show that the human brain is better at sorting the first order of magnitude (that is, everyone), and Fibonacci series jumps to distinguish numbers on the basis of the first order of magnitude, making it easier for the brain to make decisions. Although 1 and 2 are easy to distinguish, the larger the number, such as 8 and 9, it will become difficult to distinguish. At this time, 8 and 13 can improve the discrimination. Some people may ask, what if some user stories are greater than 13? You can try to make this user story smaller. What if the user story can't be smaller or not yet? Then you can use a big number, such as 20,40, 100. It is not recommended to list the numbers above 13 completely according to Fibonacci sequence, because those numbers (2 1, 34, 55) are really difficult to remember. Since they are large user stories to be dismantled, it doesn't hurt to mark them with integers.

In the iterative carding meeting or planning meeting, poker can be used for estimation, as follows.

1. Explain the meaning of 1, 2,3,5,8,13,20,40, 100.

You can choose several numbers to define what the corresponding user story is. The more common definitions are 1, 3,5.

For example:

If this is the first estimate, define the difficulty standard with the team. If it is not the first estimate, it is necessary to review whether the previous standards have changed.

2.PO or users read user stories and show the expected functions to the team.

During this period, the team can ask any questions, and PO or users will answer Chen Qing.

Everyone secretly chooses a poker spot.

The points you choose are kept secret for the time being, and the cards in your hand must be announced at the same time. The purpose of this rule is to prevent the mutual influence of decision-making among team members.

4. The people with the highest score and the lowest score Chen Qing why they scored.

There may be many reasons, such as inconsistent understanding of requirements, misunderstanding of integral standards and different realization methods. In any case, Chen Qing's discussion is necessary, and if necessary, their reasons need to be recorded. The content of these discussions may be very useful in the development process.

5. On the basis of discussion, repeat step 3 for another evaluation until the team reaches a basic agreement.

A week's iteration usually takes two hours to estimate, and some people will say that it will waste a lot of time if everyone participates. Therefore, some teams will choose to let some people participate, perhaps senior staff or team members take turns to participate. But in this way, people who didn't attend the meeting will spend more time to understand what happened at the meeting, or people who didn't attend the meeting have better solutions, but they lost the opportunity to propose solutions at the estimated meeting. It is wise to involve everyone, because self-estimation is the process of collecting everyone's opinions, and experts from various functional teams are the best candidates for estimation. If you hear complaints that too many people attend the estimation meeting affect efficiency, you should consider whether to split the team or use a more effective organization form.

The estimation result is important, but the thinking collision in the estimation process is the more important purpose.

In traditional project management, the project is estimated by "people and days" and story points are used in scrum. So what is the conversion relationship between the two? For example, it is 200 kilometers from Shanghai to Hangzhou, and it takes 3 hours by car. The story point is like measuring the distance between the two places, and "man-day" is like measuring how long it will take. The conversion between these two measurement methods is based on how fast it is. 200 kilometers, 3 hours by car and 2 hours by train. Similarly, for a project with a score of 1000, a senior team needs 60 working days, and a junior team may need 180 "working days".

If someone in the company insists on switching between the two, it is suggested to cancel the concept of story point and estimate it directly in "days" or "hours".

Relative estimation means setting a standard in advance, comparing other projects with this standard, and getting a relative result. For example, if we know that the height of Building A is 100 m, and it seems that Building B is twice as high, we can estimate that the height of Building B is 200, the height of Building C is between A and B, the height of Building C is 150 m, and the height of Building D is also in A and B..

Absolute estimation is a more accurate estimation method, that is, with the help of tools, it is estimated that the height of building A is 103m and the height of building B is 194m.

Why do we choose to use relative estimation when estimating the number of story points?

People often think that story number is the workload to complete a function, but in fact it is only one aspect of story number, which should include all efforts to develop a function, and it is affected by many factors such as complexity, uncertainty, risk and workload.

Story points are suitable for estimating long-term plans, but not for estimating tasks at hand.

Imagine talking about two kinds of statements at the morning meeting, which one is better understood?

Obviously, the first way is more specific and easier to understand. The number of story points is a rough and relative estimate, which is suitable for long-term project estimation and easy to reach an understanding, but when we discuss our daily work, time is more grounded.

The usual practice is to estimate a function by story points, but how to complete this function is tracked within hours or days after it is broken down into tasks. For example, the job search function of the recruitment website has a story point of 8. Then front-end, back-end and testing will split this function into different small tasks, which will be completed by different members. The back-end task takes 6 hours to complete, the front-end task is divided into two, and Xiao Wang and Xiao Li each do 4 hours. When the morning meeting is updated every day, everyone will also update their tasks.

In this paper, it has been clarified that the story point is only an estimate of the workload and cannot be directly used as a commitment of the team to complete the workload in the current iteration.

So, how to get the team to start commitment, and what is the basis of commitment? Before that, let's learn what team speed is. A relatively stable team, in a stable environment, the number of story points that can be completed in an iteration is the rate. This is an ideal definition. In practice, the average ratio is usually used to calculate the average ratio of the past five iterations after excluding those iterations that have taken a long vacation or the team has made major adjustments.

With the average rate, there is a basis for commitment. Of course, the average rate is only a reference, and the actual situation of the team's current iteration should be considered. For example, team members have to ask for leave, and the functions to be completed are too dependent on other teams.

The project manager cares about the estimated workload of the product, how many people need it and how much money it costs. The boss cares about when the product will go online and whether it can make money. So a single iterative plan can't answer the boss's question, so we will definitely make a long plan. The project manager patted his head to figure out the date? Or try the following two ways.

The purpose of evaluation is to make a better plan. Shopping malls, like battlefields, are changing rapidly. A fixed plan is not a good plan, and it needs to be adjusted from time to time.