Reading Notes: Agile estimation and planning

 

I recently read agile estimation and planning. This book is of great practical significance for agile development,

Provides many practical operations and tool sets. The following is the core of this book: 12 guiding principles for agile estimation and planning"

1. involve the entire group.(Playing cards)

The main responsibilities of a specific activity may fall on an individual or a group. For example, determining the priority of a requirement is mainly the responsibility of the product owner. However, the entire team should be involved and make a commitment when it is most likely to have high value projects. For example, we can see this in a suggestion. Although this suggestion is obviously only 1 ~ Two specific team members process the story or task being estimated, but the estimation made by the entire group is the best. The more responsibilities the group members share, the more successes the group can share.

2. Planning at different levels.(Product backlog-> spring backlog-> task-> daily plan)

Do not mistakenly think that the release plan will make the iteration plan useless, and the opposite will be the same. The release plan, iteration plan, and daily plan cover different time ranges with different precision and have their own specific purposes.

3. Use different measurement units to make the estimation of the scale and duration independent.(Relationship between scale and workload, story)

The best way to clearly differentiate the estimation of scale and duration is to use independent measurement units that do not cause confusion. Using story points to estimate the scale and then converting the scale to the duration is a good way to accomplish this.

4. Use functions or dates to reflect uncertainty.(The date range is given. It is estimated that it is not a commitment)

No plan is inevitable. Determine that any release plan you plan contains an embodiment of uncertainty. If the number of new features is fixed, the uncertainty is expressed as a date range ("we will finish in the third quarter" or "we will be in the 7 ~ "). If the date is fixed, it needs to indicate uncertainty about the exact functionality to be delivered ("we will finish it in December 31, and the product will at least include these new features, it may only include those new features at most "). When there is a large uncertainty, a large unit is used (such as iteration, month, and quarter after ).

5. Frequent re-planning.(Rolling plan)

Evaluate the relevance of the current release at the beginning of each new iteration. Update a release plan based on outdated information or assumptions that are currently proven to be incorrect. Use the re-planning opportunity to ensure that the project is always aimed at delivering the greatest value to the company.

6. track progress and communicate.(Mutual supervision and Supervision)

Many stakeholders are very interested in the progress of the project. Let the Group know the progress by releasing simple and easy-to-understand indicators about the group's progress on a regular basis. The dissipation chart and other project progress indicators that can be viewed at a Glance are the best.

7. Acknowledge the importance of learning.

Because projects increase new capabilities to products and generate new knowledge, they must be updated to include the new knowledge. As we learn more about the customer's needs, new features will be added to the project. As we learn more about the technologies we use or our cooperation, we will adjust our expectations for the progress rate and the methods we hope to adopt.

8. Plan to have functions of an appropriate scale.(Granularity of story points, short-cycle iteration)

Features to be added in the near future (in the next few iterations) should be broken down into relatively small user stories-usually 1 ~ 2 days, up to 10 days. We are best at estimating that the scale is within an order of magnitude. Putting user stories in this scope can bring us the best combination of workload and accuracy in estimation and planning. It also provides a small enough user story for most groups to be integrated in one iteration. Of course, it is very troublesome to use a small user story in a long project. To balance this impact, if the release plan you want to establish covers more than 2 ~ For three months, you may be able to write a larger story (called an epic) or use a theme to estimate the work that is more distant, in this way, you can avoid breaking the story into small stories too early.

9. determine the function priority.(Basic Plan, scale, and priority)

Functions are processed in the order that the total project value is the highest. In addition to the value and cost of a function, you must consider the learning effects it brings and the risks of developing it. The possibility of eliminating a significant risk in the early stage is often enough to ensure the rationality of developing a function first. Similarly, if developing a specific feature allows the team to gain a lot of knowledge about the product or their work, we should also consider developing this feature as soon as possible.

10. Build estimation and plan on reality(Plan and estimate based on the actual situation)

If possible, your estimation and plan will be based on reality. Indeed, in some cases, companies may need to estimate the speed of things without any factual justification. However, if possible, an estimation and plan should be established based on the measured values of facts. This is also suitable for the question about how many functions are completed. It is easy to know that a function has completed 0% (we have not started to process it ), it is also quite easy to know that we have completed 100% of the time (all the satisfied conditions tests of the product owner have passed ). It is difficult between the two.-Is this task completed by 50% or 60%? Because this problem is too difficult, it is best to stick to what you know: 0% or 100%.

11. retain some relaxation.(Project progress and personnel buffering)

Especially when planning an iteration, do not plan to use 100% of all group members. Just like when the road reaches 100% capacity, if everyone's time is planned to work at full capacity, the development team's progress will also slow down.

12. Create a group through forward-looking planning and coordination.

In a project involving multiple development teams, they should coordinate their work through rolling forward planning. You can plan and adjust dependencies between groups by looking ahead and assigning specific functions to specific iterations that are coming soon.