Agile Estimation in Scrum? Story Point and Planning Poker

For the owner of the project or product, this is a very important information for their measurement of project resources and timelines, but practice This has caused many problems.

Many developers always feel that PM is using the deadline to push back and forth. They don’t care whether the feature can be finished in quality.

“Get it done first, then seek better” has therefore been circulating in the software industry for a long time.

Many PMs always feel that developers are most tend to “Exaggerate” when they estimate their work. It seems that they all use the typical work estimation method: “Estimate a three-fold of the actual time as buffer” “

In fact, working hours cannot be estimated to be “absolutely accurate”, but there are some ways to estimate “relatively objective”. Due to the complexity of working hours and requirements, there is often a positive correlation. Therefore, this article will first explain the common problems in response to the complexity of the requirements, propose a proposed solution, and explain the purpose of many designs in the solution.

Problems

Developer’s Mine

“It’s very simple. It shouldn’t take too long to make it?”
PM said to you today: “I have to hand it over before tomorrow. “Get it done before seeking for quality”
PM said to you the day after tomorrow: “Why is the quality of the program so bad?”
When it has been delayed, other colleagues: “How do you need to spend such a long time? This has a ready-made code for reference. This has a good bottom layer to use. Why didn’t you ask me?”
Other colleagues: “I only need one day, why do you have spent so many days?”
“This is common sense! If we don’t mention the requirement, You should know what to do.”

PM/PO’s mine

“Why is it so simple? It takes so long?”
“Why do you see that you are visiting Facebook, but you have no time to make it?”
“Why is the quality of the things that are made so bad?”
“Why did he make it the last time, how many days do you have to do?”
Because the specifications or requirements are not clearly written, the developer is described as a requirement change.

Result

Role hostility: The demand unit and the development unit are no longer to deliver a product that can bring benefits to the user, but to attack each other for their own purposes, in order to avoid having to bear additional responsibilities. Therefore, the situation that the demand unit and the development unit are not a single team at all.
Responsibility: The team thinks that “I am not wrong, so delay is not my responsibility”, Instead of prioritizing user needs.
Demand freeze: Developers are forced to change their requirements because of deadline pressure, otherwise they will be delayed and the responsibility will be counted on the developer. Consequently, either required to overtime work to produce something that hides a lot of bugs, or to make some kind of feature that does not meet the needs of users; and both will reduce user satisfaction.
Low quality: The status of PM is often higher than that of developers. Therefore, in order to meet the deadline of the contract or to avoid penalties, etc., the team will be asked to “Get done first, then seek better”, but finally It is often “first, there is no time to seek good.” The accumulation of technical debt is increasing, and the result is the real-world chain of responsibility model, which has the greatest responsibility and cost at the very end of the chain. So the team is like stack pop, developers can’t sustain one by one, which is one of the factors why project company engineers often have high turnover rates.
Raising the weight of the code: In order to optimize the efficiency, the position of the most familiar person is always used to estimate the working hours, so the person who is most familiar with the module and process will always be concerned with the relevant requirements. In the end, only those people can maintain their own code, it is like a Pandora’s box, you never know which cows and ghosts will run out after opening. Because the black box is often filthy, but the company had no idea how to solve this problem. You also hope that he will not leave, otherwise some of the code will not be understood.

Solutions

The proposed solution here is a common way to estimate the complexity of requirements in Scrum, but even if it is not a Scrum team, it is recommended that readers be able to identify the best way to estimate your team based on the principles and design objectives.

Keep in mind that without a silver bullet, someone else’s best practice doesn’t necessarily apply to your team, so first understand what the problem your team is currently experiencing, and then find out what’s right for you to solve the problem from someone else’s practice, as long as it doesn’t give rise to new problems or the cost risk of a new problem is acceptable.

The unit used here to estimate the complexity of requirements is story point (relative unit), not working hours (absolute units).

The unit used to estimate the complexity of the demand here is the story point (relative unit), not the working time (absolute unit). There are several reasons for doing this:

1. Comparisons do not vary from person to place: the complexity of requirement often does not vary from person to person, and the time required for practice will vary from person to person.

2. “Relative” is easier to evaluate than “Absolute”: If you look at working hours, you will need to estimate the absolute number, and you will need to think about the implementation details in the estimation process. To use the story point to estimate the complexity, you only need to compare the size with other requirements.

For example, it is hard to say clearly that “A Tower is a few meters high”, but it is easier to point out that “This Tower is about 2 times higher than the that building.”

3. The pressure for estimating the story point of a user story is smaller than the estimating its work time: focus on the requirement itself, without worrying about its own resources and project resources, simply assess the complexity of the requirement. During the estimation process, team members are less stressed and play a part of software development like a game.

Although the complexity of the demand is often positively related to the working hours, because of the different implementation conditions, it is still possible to have a feature with a high story point, and the demand for working hours is lower than the story point. But in Scrum, you can use the iteration sprint to evaluate how much complexity each sprint team can digest. For PO/PM, instead of estimating an unsuccessful time course, it is better to estimate a more accurate and objective time course so that they can understand at the first time, how far away from the expected time course of the project. If resources are limited, how to prioritize requirements or seek other support.

Next, explain the various aspects of the solution.

When

Conduct an assessment before deciding who needs to do it: The benefit of doing so is to minimize the personal factors of the developer. Because you don’t know who is going to do it, there is no need to over-estimate for adding buffer due to the task or deadline of your own.

Who

Only the people who do things to evaluate together: two key points:

Only people who do things can be estimated. The time or complexity estimated by the requirement unit is not objective, because they are not the actual person who does the work, and there is no power to influence the development team’s estimation based on the work afford assessment. This also makes it easier to avoid the evaluation of the complexity of the requirements from deadline.
People who do things together estimate. Because you don’t know who is going to do it, the figures that each person estimates together are easy to reach consensus after discussion and re-estimation. Everyone has the participation, they will have a sense of participation, and because everyone has the participation, the estimation result is decided by everyone, so who will do it in the future will not complain.

What

Use the Planning Poker to estimate the story point.

Poker card and Fibonacci sequence

The Fischer series has an interesting feature, and each number is the first two numbers added. On the other hand, the bigger the difference between the number and the next one, the bigger the difference.

As shown above, the gap between 8 and 13 is 5, and the difference between 13 and 20 is 7. However, how does this relate to estimating the complexity of demand? We are not in math class.

Characteristics of Estimation Related to Fibonacci sequence

Estimates also have a characteristic, that is, the bigger the more accurate, the larger the demand or task is cut to a finer granularity, it is often estimated to be more accurate. Just like if a large irregular piece of stone is installed in a cup, there will be more gaps in the middle, which is the part that is out of alignment or wasted. If you install a stone with a finer size and the same irregularity, the gap will be relatively small, and it is easy to adjust, and it can fill the gap more conveniently.

Even if the difference in the previous figures is relatively small, it doesn’t matter because the number is small, which means that the movement is flexible and the risk is low. If the time estimate is inaccurate due to certain factors, the task of the small number in front is about 20 minutes of overtime. Instead of working overtime for 2 or 5 days.

Because the large digital gap is large (the difference ratio of the two front and rear values of the Fermi series is close to 1.618), it is possible to avoid the estimation of “whether this complexity is 20 or 21”. “ If you want 13, you want 20, you want 40.

Such a gap can highlight the difference in estimates of the same requirement, because almost all of them are more than 1.5 times worse. This ratio is quite easy for humans to judge relative size, and therefore can reduce many nuances and unnecessary Re-estimate process costs.

Special Numbers in Poker Card

In addition, the above picture can be seen with a few special numbers, which are 0, infinity, and question mark.

0 may mean that this requirement does not need to be done at all, or it has already been completed.
Infinity means that the demand is clear, but the one that exceeds the maximum number indicates that the demand needs to be subdivided into multiple smaller-sized requirements.
The question mark indicates that the demand is not clear and needs PO/PM to explain or clarify.

How

1. First define the unit of complexity 1 , such as the function of a single table comprehensive query. Because our estimation process is based on relative size, we first define the unit of comparison benchmark, and there is a basis for comparison after the team estimates.

2. The host speaks aloud the requirements (such as the User Story Card) to make sure that everyone understands the requirements and each person presents their own estimated complexity. The reason for using planning poker is because the figures that you evaluate can be presented at the same time, instead of rotating the numbers you have evaluated. It is easy to turn the numbers out and cause the results of the people behind them to be affected by the previous figures.

3. If there are different estimates in the team, the two are estimated to be the smallest and the largest, and they will assess why they are complicated or simple. In the above example, in the estimation process, if one person estimates that the story point is 13, most people estimate 20 and another person estimates 40. 13 and 40 are almost 3 times worse, so basically there must be some important information that has not been synchronized.

For example, people who estimate 13 think that this demand is almost the same as a requirement in the past, and this requirement is not as complicated as imagined. The person who estimates 40 may feel relatively complicated because he is not familiar enough with this requirement or process.

4. Minimum and maximum figures the reasons for the assessment are completed and a further vote is held. If there are still different numbers of votes, and the vast majority of people have a consensus, and there is no consensus that the estimated complexity is only one level away from the consensus complexity, you can ask the members who estimate the different numbers whether they can accept the figures that you have assessed.

5. If the number still has a gap above a level, or if consensus cannot be obtained, repeat steps 3 through 5 until consensus is reached.

Again, only those who actually perform tasks or complete the requirements can participate in the voting process, and PO/PM cannot interfere.

Why

There are several advantages to this way of estimating:

The person who is working together decides a reasonable and objective estimation result, has a sense of participation and has no complaints.
The result of the decision is the consensus between PO and Team, which will reduce the occurrence of tit-for-tat situations in the future.
Everyone can understand the requirement. In the future, everyone can act as the person to fulfill the requirement. When the requirement for support is needed, people can also help or support each other.
Before you have done so, you can clarify the part of the requirement that is not clear and the part that has doubts.
Before you can do it, you can find the best and most efficient way to work in the team.
Unless the entire team is a undependable person, this number reflects the fact that the estimate is shared by the team, and PO can understand the gap between demand and evaluation.
By comparing the relative size of the complexity between requirements, the future PO will be able to promise how much work can be fulfilled in a iteration, and there will be a basis for comparison.

Conclusion

Through the above estimation process, such a decision is open, transparent, objective and consensual. For two roles:

For PO/PM:

Don’t worry about being over-estimate a task for a buffer by certain members.
Understanding the underlying difficulty of implementing requirements or tasks in the assessment process.
Understand whether there are any parts of the requirement that need to be clearly stated or misunderstood.

For team:

People who are no longer doing things are given an unreasonable time limit in accordance with deadline.
Knowledge exchange between developers before they start working on the task. Regardless of whether the estimated number is increased or decreased, the demand is more clear and the estimate is more objective.
Because you still don’t know who is claiming this task, so the estimation process can be achieved objectively and with team consensus, you know who is familiar with this task through the process. When you actually do it, you can pair programming or know who to ask for help.

The solution proposed in this paper is a common solution. The focus is not on the form, but on the design purpose of each link in the agile estimation process, in order to solve what kind of problem.