Again on story points

Ron Jeffries is the founder of extreme programming concepts, one of the 17 authors of the Agile Manifesto, and the first extreme programming coach. The original link: ronjeffries.com/articles/01…

Takeaway:

This article goes into more detail on why Ron, the inventor of the concept of “story points,” doesn’t use points much anymore. He believes that “story points” have many disadvantages, such as leading to cut-throat competition and team work out of focus. At the same time, he also gives suggestions for agile development after weakening points.

For teams that are adopting agile working methods, this article will bring new thinking and perspective.

I may be the one who invented the concept of “story points” in agile estimation, but I’m sorry for that now. Here’s what I think of “story points” so far, in the hope that someone will be interested. – Ron Jeffries

First, “user story” was originally a concept in XP (Extreme Programming), not Scrum. Somehow, later practitioners of the Scrum framework picked up on this idea. Even the official Scrum Guide describes the “requirements backlog” as being presented as “user stories.” Up to a point, this is right.

I’ve written a little bit about “user stories” before. In this article, however, we will only discuss “story points” in agile estimation, which will be referred to as “points” below. In XP, the initial estimate of user story effort is the time required to implement the requirement.

Start by estimating the ideal number of days you would need to use the feature if you had to concentrate on writing it. Then, ideal days x negative factor = actual implementation time. If the negative factor is about 3, it will actually take 3 days to complete an ideal day’s work.

In communication, however, we usually don’t say “ideal day” directly. As a result, project managers often ask why it took three days to do one day’s work. Put it another way: Why can’t we do 50 days of work in three weeks?

To avoid internal friction, in Agile development, we reduce the “ideal days” to an imaginary number of “points”. For example: Implementing a user story takes three points of work, which might mean it takes about nine days. In fact, we wanted to use just “points” to control the total amount of work per iteration. So when we say we can do about 20 points in this iteration, no one really objects.

I thought about changing the name of “points”, but now I have a new idea about the problem. Until my colleague Simon asked me: Do you really regret inventing points, or do you regret that they are misunderstood and abused?

My answer is:

  • I am, of course, only sorry that they have been abused;
  • I think it’s a bad idea to use them to estimate “task completion time”;
  • It is futile to compare actual progress with estimated points;
  • Comparing the accuracy of estimates between different teams is detrimental.

A closer look reveals that, in fact, some so-called “agile” teams are turning “story points” into “standard hours” in the name of “ease of planning.” Although it seems reasonable on the face of it, it’s easy to fall into the trap of competing for workload.

—

Trap # 1: Keeping up with the Joneses

First, even if the requirements look the same, each team will score very different points because of their different methods, habits, and circumstances.

So, even though two seemingly identical requirements, it’s likely that team A will need two points and team B will need six points. Obviously, this is not a direct comparison.

However, managers try to solve the problem by first asking whether requirements can be compared; Explore whether the team that consumes more hours needs help. This implies a bad judgment: “slower” teams are worse, or are in some kind of trouble.

When there are two teams working in parallel, it is tempting for many managers to compare their workloads. But this is likely to lead to “quantity over quality”. So I decided to do as little workload assessment as possible.

—

Trap # 2: Evaluation

In the eyes of many project managers: the number of points is the number of people. This means comparing the points to the actual time spent and trying to ensure the accuracy of the estimated points. Otherwise, the ability of developers needs to be improved. That’s bad.

To me, true agile development is finding the most valuable feature and implementing it quickly. Rapid development, on the other hand, requires completing the highest value requirements in a feature first, and then iterating. Estimating “points” does little to help.

Instead, the presence of “points” causes management to take their eyes off “story value” and focus on improving the accuracy of the workload assessment. So I think: If using “points” is distracting the team from “value,” let’s drop the concept.

—

Trap # 3: Stress

Once “points” are equated with actual hours worked, managers naturally apply pressure: they want “more”. The team has a lot to do, but it’s not enough. It can be more, more, more… But the best way to get value out is not by heaping, but by making small, valuable requests on a regular basis.

If we don’t measure the workload, but instead slice the requirements into “small enough” slices, then we can deliver value more smoothly and consistently.

An excessive focus on quantity can hinder growth in value. The stress of pursuing only the workload will inevitably lead to a bad result: the team will appear to develop faster, but end up with less quality. More bugs in new releases, frequent bug fixes slow down iterations, and a rapid decline in code quality affects quality… Things get worse and worse, adding to the stress, and finally sliding into disaster.

As you can see, using “points” the wrong way can put the wrong amount of pressure, so I’d rather avoid it. Further: I don’t even want to use the concept of iterations or sprints anymore. Instead of filling out the number of tasks for the next few weeks, we chose to list the most important things to do next.

—

Predicted completion time?

In the past iteration planning has been to list some basic features and figure out how to piece them together into the next version of the product. Follow up with: When will it be done? The answer is: no one knows.

We can certainly improve this lack of understanding, but when we are developing solutions for internal or external customers, it is better to deliver small, visible values at high frequencies; Rather than planning a major release that will be feature-shattering but will never be completed.

The best practice is to choose a deadline for the next release for your customers and to include more utility features in that release. Predicting completion time, whether you do it in story points, people, or any metric, gets in the way. That’s why I think people should use fewer “points” to plan their work.

—

Story slice √

This raises a new question: If I don’t like “story points,” what do I like? A: I love “story slices.”

Break large requirements into smaller user stories, ensuring that each story is as high value as possible, but requires very little work to implement it. Ideally, it should be less than a day, or even just 2-3 hours.

I’m not going to argue with you about whether or not a story slice should also estimate the amount of work. If you or your team only do the math in your head and don’t tell anyone, then the problem with “estimating points” won’t arise. Moreover, the perception of “three days versus one day” is very different from the perception of the difference between “needs are small enough or not small enough.”

—

What to do in the future

Of course, if you have to assess the workload, go ahead. But I still think there’s a better way:

First, consider the core features of each release. Discuss what problems they will solve, what solutions are available, how to do MVP… We don’t have to solve all the problems that exist. In fact, providing some value is enough to get delivery going.

Second, set a deadline and choose the point at which you think you can deliver the high availability feature.

Third, do “story slices” for important features. Cut requirements into tasks that can be completed in a day or less. Focus on the “next most important feature.” Do not always go to sew the original function, screw shell do dojo. Try to create a new frame of mind: “The little point that the client master will actually use is the feature point that we want to do.” Then, be an MVP and let the client try.

Only then can we continue to produce value as quickly as possible. We want to make the value of the development work visible so that both product owners and users can’t wait to see what we deliver. No matter how much work we do, we should do what is right and valuable.

—

In a nutshell

If I had invented story points, I might be sorry now, but I don’t really regret it. I do think that “points” are often misused: using them mechanically to plan your development schedule can lead to a lot of pitfalls.

If “points” don’t provide much value to your team, I suggest you don’t use them too persistently. On the other hand, THERE are other articles I’ve written about how to use story points well that you can refer to on this blog.

Read more “story points” best practices, learn about the different frameworks of Agile development, learn more about agile… Follow the gold diggers at @Ligaai

To learn more about our products, please visit LigaAI – A new Generation intelligent R&D Management Platform