When I coach my team on story point estimates for user stories, I often run into the following questions:
- Why use story points instead of time to estimate user story workload?
- Why use the Fibonacci sequence for story point estimation?
- Why were the numbers in the Fibonacci sequence changed?
- Why Estimate Poker?
- Why a baseline story?
- How do you determine the baseline story?
- How do other stories measure up against the base story?
- …
After looking through a lot of scattered data, I finally got these questions straight. If you have any of these problems, take some time to read this article and you won’t be disappointed.
1. Why use story points instead of time
Before we answer that question, let’s look at an example:
Han Meimei went running with Li Lei in Beijing Olympic Forest Park. Li Lei said to Han Meimei, Let’s go to the Nanyuan Road. It will take about 30 minutes.
Han Meimei knew the route well, but being a slow runner, she knew it would take 60 minutes. So Han Meimei told Li Lei that it would take her 60 minutes to run across the road.
Then they argued: 30-60-30-60…
They argue for a long time with no result. As a keen observer, you might urge them to compromise, say, for 45 minutes. But that was the worst possible outcome, because although they came up with a compromise solution, it was not realistic for either party: too slow for Li Lei and too fast for Han Meimei.
So, they went on arguing: 30-60-30-60…
Finally, Li Lei told Han Meimei, The road to Nanyuan is about five kilometers and I can run it in 30 minutes.
I agree the distance is 5km, but it will take me 60 minutes, Han said.
They are both right: Li Lei really can run in 30 minutes, and Han Meimei really needs 60 minutes. But when they tried to create a uniform estimate for the distance, they found that they couldn’t because people ran at different rates.
However, when they used an abstract unit of measurement of length (km), they quickly came to an agreement. Both Li Lei and Han Meimei agreed that the distance was 5 kilometers, but because of their different speeds (relative measures), so did the time they took (absolute measures).
Many of you may already have a formula in mind: distance (km) = speed (km/h) * time (h). So why do I give this example? Is it just to remind you of elementary school math?
In fact, the workload of a task in software development is very similar to the “distance” of running: the same task, no matter who is doing it, the workload is the same, but the competent person will do it faster (less time); The less able people do it more slowly.
Similar to running, if we get multiple people to agree on how long the same development task takes, it’s difficult, but if we can have a unit that describes the amount of software development effort (like KMS for example), we may be able to reach an agreement quickly. A “story point” is a unit of effort created by agile development to represent a development task. It does much the same thing as the “km” used in the example to represent a unit of distance: it allows people of different skill levels and speeds to quickly agree on an estimate of effort. Of course, the protagonist of agile development is the developer with different productivity, not the runner with different running speeds in this example.
Like these two runners, two programmers might agree that a user story is five story points (in the analogy example, 5km is an abstract unit of measure). A senior developer might think this is easy and can be done in a day. A junior developer might think it takes two days to get it done. But they can quickly agreed on five story points, because the first user story as a five point is don’t need any basis (like the definition of different countries or regions on the length of the unit may be different, such as meters, inches and inches, each team of the size of the story points also can have their own standards, as long as the team members are approved).
Most importantly, though, once they agree that the first story’s workload is five points, the two developers can agree on subsequent estimates. If the senior developer believes that a new user story will take two days (twice as long as his estimate of a 5-point story), he will evaluate the new story at 10 points. A junior developer will do the same, and when he estimates that it will take four working days (twice as long as his estimate of a five-point story), he will evaluate the new story at 10 points.
So, the reason to use story points instead of time is that they allow developers with different abilities to quickly agree on the same task estimates.
Why use the Fibonacci sequence to estimate story points
2.1 People cannot tell a difference that is too small
German physiologist E.H. Weber found a law through the study of weight difference feeling, that is, the difference threshold of feeling changes with the original stimulus amount, and the performance is a certain regularity, the stimulus increment (△I) and the original stimulus value (I) ratio is a constant (K), with the formula expressed that K=△I/I, This constant is called weber’s constant, weber fraction, or weber ratio.
The above definition, copied from Baidu Baike, simply states that we can only tell the difference between two objects by a certain percentage.
For example, most of us can tell 1kg from 2kg, but may not be able to tell 20kg from 21kg. They are also 1 kilogram different, why some can distinguish, some can not distinguish it? This is because the difference between 1 kg and 2 kg is 100%, but the difference between 20 kg and 21 kg is only 5%, so the percentage difference between 20 kg and 21 kg is too small.
That’s what Weber’s law is trying to tell us: the difference is so small that we can’t tell it apart; Only when the difference is large enough can we distinguish it. So what percentage of the difference can people tell?
2.2 Proportion of differences that people can distinguish
Weber’s law just tells us that we can recognize differences beyond a certain percentage difference, but what percentage is that? Nature has a magic number: 0.618, or the golden ratio.
There are many phenomena of the golden ratio around us, such as:
- A person’s navel is the golden section of the body’s total length
- Most doors and Windows also have a width to length ratio of 0.618
- In some plants, the Angle between two adjacent petioles is 137°28′, which is exactly what divides the circumference of the circle into 1:0.618
- The themes of some famous paintings, sculptures and photographic works are mostly at 0.618 of the picture
- …
Even in medicine, when a patient reports feeling better, they are actually 65 percent better.
In other words, the 61.8% percentage difference is easily discernible for many people.
2.3 The Fibonacci sequence roughly corresponds to the golden ratio
The Fibonacci sequence works well for story point estimation because the number distribution of the sequence roughly matches the golden ratio. In this series, one, two, three, five, eight, thirteen, twenty-one… After the first two values (the latter value is 100% greater than the previous value), each subsequent number is about 60% greater than the previous number value.
According to Weber’s Law, if we can tell two stories that have a 60% difference in workload, we can tell other stories that have the same percentage difference.
Thus, Fibonacci values work well because they increase by about the same percentage each time, and that ratio is roughly consistent with the golden ratio.
3. Why do agile estimates use the modified Fibonacci sequence
The standard Fibonacci sequence is 1, 2, 3, 5, 8, 13, 21, 34, 55… “, but the Fibonacci sequence most teams currently use for their estimates is 1, 2, 3, 5, 8, 13, 20, 40, 100… The first six digits in the series are the same, but from the seventh digit on, it’s completely different. Why?
Mike Cohn mentioned in his article that his early estimates were based on real Fibonacci sequences (1, 2, 3, 5, 8, 13, 21, 34, 55…). .
The further the sequence gets, the more inaccurate the estimate becomes, so many people wonder about estimates like 21, 34, and 55: why use 21 instead of rounding it to 20 or 25 when you can’t already estimate it?
So Mike Cohn took that advice, used 20 instead of 21 in his team coaching and lectures, and has continued to do so since.
Later, he experimented with the numbers 40 and 100 instead of the rest of the sequence, because the coarser the task, the less accurate the estimate, and the less you had to worry about whether it was 80, 90, or 100.
At the same time, the use of 40 and 100 does not violate Weber’s law, as they increase by 100% (20 →40) and 150% (40 →100) respectively over the previous numbers. This is much larger than the Golden Ratio of 61.8%, and people can easily tell the difference between these workloads.
Since then, under the influence of Mike Cohn, most companies now use the modified Fibonacci sequence in agile estimation: 1, 2, 3, 5, 8, 13, 20, 40, 100, infinity.
4. Why use planning poker
Many people use physical or electronic planning poker to estimate story points. Why do we do that? The problem starts with the psychological term “herd effect”.
4.1 What is the herd effect
In estimating story points, when someone makes a estimate, even if you don’t agree with, but when people express approval, you will echo, this is the so-called “herd mentality” : people think that if other people are in favor of something, so their reservations are stupid or misleading, they don’t want to make a fool of yourself in front of others.
This weakness is not unique to individuals; it is universal.
Other concepts related to the “herd effect” are the information cascade and the halo effect:
1) Information Waterfalls
This concept was first mentioned in A paper named A Theory of Fads, Fashion, Custom, and Cultural Change as Informational Cascades: An information waterfall occurs when a person observes the behavior of the previous crowd and decides that the best course of action is to give up the information he has and follow the behavior of the previous crowd.
2) Halo effect
When a cognizer forms a good or bad impression of a person’s characteristics, he tends to deduce other characteristics of the person, which is essentially a cognitive error of overgeneralization. Like the herd effect, the halo effect causes people to focus on a positive halo and ignore the actual data.
The herd effect is very harmful. What can we do to avoid it?
4.2 Use “Delphi method” to reduce the influence of conformity effect
Delphi method, also known as the expert investigation method, in 1946 by the rand corporation founder, its essence is a kind of feedback anonymous enquiry method and its process is roughly the problems on forecasting the consent of the expert’s opinion, carries on the sorting, induction, statistics, and anonymous feedback to the experts, for advice again, then concentrate, feedback, again until you get the consensus of opinion.
The RAND Corporation used this method to conduct an anonymous poll on the question “How many atomic bombs would it take for the Soviet Union to destroy major U.S. industrial targets during the Cold War?” .
They brought together a team of experts, including four economists, an expert in physical vulnerability, a systems analyst and an electrical engineer. The men are experts in a variety of fields, but the results of the first round of voting ranged widely from 50 to as many as 5,000.
After the first round of voting, all experts will organization sent to you after integration, such as the objectives of vulnerability and resilience in a wide range of industries, the safety of the factory, different parts of delivery cycle, the accuracy of the target and so on, and then organize experts conducted a second vote, down to assess differences between 89 ~ 800.
Repeatedly carrying out the above process, the final difference becomes smaller and smaller, and finally falls between 167 and 360.
The initial estimates were off by a factor of 100, and by the end, they were down by a factor of two. This tool allows experts to reach a general consensus without fear of bias.
In order to reduce the “herd effect” of user story estimation, many teams now use the independent voting method of planning poker. The detailed use of planning poker is described in Section 5.3.
5. How to estimate story points
5.1 Determine baseline story points
It is a good idea to use the same baseline user story as a point for each estimate (called the baseline story point, or how long 1km represents when representing a distance), which will be helpful for overall project statistics. Other stories are estimated relative to this baseline story, so that the workload of other stories can be calculated, and the story points completed for each iteration can be used to effectively measure the change in team productivity over each iteration.
For first time Agile teams, there can be confusion about the base story and the base story points: if the base story point is too large, there may be a lot of stories below 1 story point; If it’s too small, the story points of the other stories will be too big. Based on my practical experience, to assess story points for the first time, you can try to use a 1 time before and after the network communication, front end has a page, once the backend database interaction of user story as a benchmark, the workload positioning a story points, such as many systems have the login function, is a good benchmark story, this story no effort is too great, It’s not too easy.
5.2 Basis of Relative Estimation
Once the base story point is established, how do other stories compare to it? How do you determine how many times as much work another story takes as the base story? We can consider from the following three factors:
1) The Amount of Work to be carried out
If there is more work to be done, of course, the estimate of work will be larger. Consider two examples of web development. The first page had only a field and a label that asked for a name. The second page has 100 fields to enter a short piece of text.
The second page is no more complex than the first. There is no interaction between the fields; each field is just a bit of text. So there is no additional risk to the second page. The only difference between the two pages is that the second page has more things to do.
The second page should be given more story points. But even if it had 100 times more fields, it might still not get 100 times more points. After all, because of economies of scale, the second page might only take two or three times as much work as the first.
Risk and Uncertainty
The risk and uncertainty of a user’s story can affect its story point estimate.
If the stakeholders of the user story are vague when asking about the requirements, then the team should reflect the uncertainty in the estimates.
If implementing a feature requires changing an old piece of code that lacks automated testing and is structurally fragile, then this risk should also be reflected in the estimates.
3) Complexity
Complexity should also be considered when calculating story points. Recall our previous example of Web page development with 100 trivial text fields and no interaction between them.
Now consider another page that also has 100 fields. However, some of these fields are pop-up date fields using calendar controls; Some are formatted text fields, such as phone numbers or ID numbers; Other fields need to be checked and verified by the bank card number.
Fields on the page also interact with each other. If the user enters a number starting with 189, the operator field displays China Telecom by default. However, if the user enters a number starting with 139, the operator field shows China Mobile by default.
Although there are still only 100 fields on this page, these fields are more difficult to implement. They are more complex and take more time to implement. Developers are more likely to make mistakes, so some preventive and corrective actions have to be taken.
This additional complexity should be reflected in the estimates provided.
5.3 Use Planning Poker Group Estimate Points
(Planning Poker)
In Section 4.2, we saw how to use the “Delphi method” to reduce the impact of the herd effect. In agile development, we can use planning poker to conduct anonymous voting. At the estimation meeting, everyone on the team is given a paper poker, although with the advent of the mobile Internet, most agile teams are now using electronic poker, which is much more convenient. Here are two cards that need to be explained:
If someone plays “☕ at,” it’s a sign that you need a break.
If someone puts out a “? This poker indicates that he does not understand the demand and cannot estimate the workload. PO needs to try to clarify the demand again.
As in the case described in Section 4.2, when planning the story points, there may be a wide range of estimates in the first round. If the difference in estimates is significant, there is no consensus on the amount of work, risk and uncertainty, or complexity of the user story, and people with high and low estimates need to be given a chance to explain why they are so high. After everyone agrees on the details contained in the story, the story points will be reassessed until everyone basically agrees on the story points.
If for the same user story, the estimated number of story points may not be exactly the same, but there is not much difference between the points. For example, between 3 and 5 story points, the story points of the user story can be calculated using the average method, which is calculated by comparing the average value of the estimated points with the Fibonacci sequence. The story points with a small difference from the average value are used as the final points of the user’s story.
As in the estimation of A story, A total of seven people to participate in the estimation, with four people’s estimate of story points to 3, 3 people evaluate story points to 5, the story points after the average of 3.85, with the Fibonacci sequence in 3 and 5, and story point 3 of the average difference is smaller, so the user story end points to 3, the user story points to estimate to complete.
5.4 other
There are a lot of small details about the story point count, so I’m going to outline what I think, but I won’t go into details. If you have a better idea, please feel free to leave a comment:
1) At which meeting is the story point count done?
If there are more people attending the meeting (more than 2/3 of the team), it will be held at the meeting; If the number is small, hold a separate short estimation meeting before the scheduled meeting to make an estimate. It is not recommended to make an estimate at the planning meeting.
2) After the estimation is completed, can the cards be displayed arbitrarily?
No, the cards must be displayed together, and team members are not allowed to discuss the number of points they are counting.
3) Are PO and SM involved in estimation?
Don’t participate in. Only the development team is involved in the evaluation. Note the “development team,” which includes developers and testers, not just developers.
4) How many points more than user stories need to be split?
The base story point size is different for each team, so it is impossible to give an exact number, but it is recommended that an Agile team should not exceed 5, which can be adjusted later based on feedback from the team.
5) Should I modify the number of points if the estimation error is found in the actual development?
Don’t. Estimates are used to aid our work schedules, not to manage employee performance. Spending too much time and effort trying to get an accurate estimate is putting the cart before the horse. And in my experience, there are some stories that are underrated in an iteration, but there are also some stories that are overrated, so in the iteration as a whole, the story points don’t fluctuate much.
6) Do team estimates have to be made for very small requirements?
Want to. Assessing points is the process of aligning the team’s understanding of the requirements. If the demand is really small, the assessment process will be agreed quickly and will not take much time.
7) How do teams in scale Agile estimate baselines together?
First, gather a few key members (2-3 per team) from each team to form a cross-functional estimation team. Then, 10-20 stories are randomly selected from the entire product to-do list to define and estimate the benchmark story points. In the process of estimation, if someone is not clear about the relevant technology or requirements, he/she can give up. Finally, the participants took the 10-20 estimates back to their team, and synchronized the base story with the other stories to align their perceptions of the workload.
The resources
- The Agile Revolution, Jeff Sutherland, CITIC Publishing Group.
- Why the Fibonacci sequence works well for estimating, Mike Cohn. The main benefit of story points, Mike Cohn.
- What are story points, Mike Cohn.
- Weber’s law, Baidu Baike.
- The golden ratio, the encyclopedia.
- Fibonacci series, baidu encyclopedia.
- Delphi method, baidu encyclopedia.
- How to Estimate Story Points With Multiple Teams, Mike Cohn
The little boat brother is quick
Author: The boat brother
On April 8 PM every Thursday, skilled and magical craftsmanship of the conversation, winter elder brother to say 】 【 dismantling the conversation and specific tool of actual combat. Public message “solution cattle” can obtain the address
- 0401 “Database Continuous Delivery Pipeline Sharing and Demo (Azure DevOps+Flyway)”
- 0408 “Version management in continuous delivery and plug-in development based on the Azure DevOps extension framework”
- How to do API testing in microservices, multi-team collaboration – PACT contract testing
- 0422 “Boathouse End-to-End Pipeline Display”