Hard to practice agile: Estimation

ArticleDirectory

• Purpose of Estimation
• What can we do when we don't understand it?
• Do not perform multiplication or division for addition and subtraction.
• Summary

When talking about agility, people tend to explore TDD and continuous integration in a very high profile. At the same time, many practices are very low-key. For example, estimation. You can learn TDD with many examples. However, learning estimation cannot help. After "messing up" a few projects, it seems that I have touched some doorways.

Purpose of Estimation

In my opinion, estimation has two completely different purposes. The first is the quotation, and the second is the planning. In order to make a quotation, we are pursuing the absolute size of all the story cards. To guide release planning and make adjustments in iterative development, we are pursuing the accuracy of the relative size between story cards. However, both goals are hard to achieve.

Unreliable

First of all, I want to estimate the absolute size of the story card, and then take the quotation. TMD is just pulling -- light --. But who makes us a small role, and the leaders let you make an estimation? Do you want to do it? So we have to do it. However, do not do it seriously. Finally, we need to get the code one by one.CodeIsn't our minor roles even unlucky? Therefore, even if you think it is not reliable to estimate the absolute size, you have to make sure that you are doing it carefully.

I understand your pain. Agile is never intended to write stories at the beginning of the project so that we can understand them. If the acceptance conditions are clearly written at the beginning, and then several fingerprints are pressed, It is not agile. Therefore, from the very beginning agile is to play with our developers. You have to be prepared for this.

Generally, there is a requirement collection phase at the beginning of the project. Fortunately, you are also involved in this phase. Then, there will be business analysts who will write a list of stories and cards for high-rise buildings. What do you do after getting the story card list?

First thing

The first thing is to browse the entire list and try to summarize the ideas that business analysts use to divide the story. If we regard the entire project as a group of mud:

The story written by business analysts is the first splitting of the story:

When we write code and turn a story card into a dozen classes, we split it for the second time:

So, weProgramWhat employees and business analysts do is essentially the same. A business analyst is responsible for writing the story card to the minimum level and writing it to the "externally visible" location to the minimum level. But the invisible external part, that is, the collaboration between classes and other object-oriented modeling is done by our programmers. Therefore, the story written by good business analysts can be easily written. However, we are not in the ideal world, are we? It is impossible to assign the strongest business analyst to every project. Most of the time, you may laugh at the list of stories. The phenomenon is that there is not enough story to cover a complicated thing. It is very simple, or something of the same nature, but a bunch of stories have been written. So you need to do two things.

The first thing is to check for missing information. No matter how well the story list looks like, you have to be aware of the entire process. Then confirm there are no missing stories. The second thing is to look for duplicates, probably understand how they are implemented, and analyze whether there are duplicates between stories from the implementation perspective.

The worst case is that the splitting angle of a business analyst is completely incorrect, and the system changes are not grasped during splitting (actually the place where Code complexity is located ). It is very dangerous to start estimation if you do not know the whole. Developers must be tough at this time. They must propose missing stories, remove repeated stories, and require them to rework the list of completely wrong stories.

What can we do when we don't understand it?

Don't expect that there will be many words on the story card at the beginning of the project. Let you estimate, you cannot calculate. If it's hard for you to tell your project manager, why don't you come? No, no way. At this time, you should first talk to business analysts to learn as much details as possible. However, in the quote phase or in the early stage of the project, business analysts are not very familiar with the business, and we do not have enough time to investigate and understand the business. Therefore, in the real world, you must make an estimation without sufficient information. At this time, you have two options:

1. Reject Estimation

Sometimes, we can say no. Absurd estimation can harm others. Don't count on it. A "big enough" estimate can cover you. By estimating small stories, we can only make other real stories relatively small. Do not give 10 or 8 numbers without spectrum. Do not randomly select a very large value from all your estimates. Because once you select this value, for example, 10, the Project Manager will really plan the release plan as 10, which means five 2 story cards, 3 multi-3 story cards. Are you sure you want to ask yourself that there are so many 5 2 story cards? Or is this enough? 10 is not 10. 10 means you "don't know ". Programmers can say no.

2. Make some assumptions, write down the assumptions, and then make an estimation based on the assumptions.

This is the last resort, especially if you want to make a quotation. You must write down your assumptions. Because you will forget that you will leave the project. You don't want your colleagues to scold you for implementing this story card, right? Please write every assumption you make, such as not including the database and only the front-end interface, next to your estimation. The rest is to pray that your project manager and business analyst will respect your assumptions during iterative development. When the assumption changes, let the customer know that we have done extra things beyond the scope of estimation, and you must compensate me (... Ideally)

Do not perform multiplication or division for addition and subtraction.

There are two types of la。 s in specific estimation. One is multiplication and division, and the other is addition and subtraction.

1. multiplication and division

Select a story card called a point. Then other stories are compared with the card of this point to get their estimation. If it takes two times, it is two points. If it is three times, it is three points.

2. addition and subtraction

Select a medium-size story card. Then other stories are compared with this card. We add one, which is much larger than this card. We add two, which is a little smaller than this card, we subtract one, which is much smaller than it. We subtract two.

In my opinion, do not use multiplication and division, but use addition and subtraction only. Because people are not very good at measuring the multiples of two objects. Even after the project is completed, you may not be able to accurately estimate the multiples of the two story cards. In addition, a good story should be of the same size. If the size difference of the story is three times that of the normal state, I think this is not normal. Theoretically, the smallest and largest story card should be about twice the size. If it is too large, it means we do not understand the business, or there is a problem with the splitting method. In particular, you need to understand that estimation guides iterative development. You can estimate that a card is at 8 points. It takes four cards at 2 points to match the card. If multiplication and division are used, the size of the story card is often very different. Is there a very wide gap in actual development? The estimated values of personal recommendations are 2, 3, 4, and 5. Generally, take 2 or 3, the bigger 4, and the bigger 5 with some risks. If it is bigger, you should consider splitting the story.

Summary

Estimation is a weakness of agility. It is also a key link in a successful Agile Project. Traditional projects, pre-design, closed contract, and many other things have a set of methodologies to guide us in estimation. In this regard, agility undoubtedly shirks the burden to specific people. There are still many things worth studying and Exploring about estimation.