In Agile project management, we often use the term story estimation when reviewing user stories.

In this article we will talk about what are the story points in Agile development? And how to evaluate stories.

Say first concept

Story point, an abstract unit of measure used in Agile project management and development to estimate the complexity of implementing one or more user stories, is a way of describing metrics. A story point is a number that tells the team the complexity of the user story.

Complexity includes how easy the functionality is, how risky it is, and how long it takes.

The story point could be an ideal workday: no interruptions, no meetings, no emails, no phone calls, no distractions, etc. Teams can use story points as a measure of user story complexity.

Team estimation

Story estimation should be done by the entire team. In agile R&D management, we find that some stories may involve multiple tasks, and the task estimation belongs to the team members performing the task.

There are major reasons why story estimation needs to be done by all members:

First, until the story is estimated, it is not clear who on the team is responsible for completing the story, so the story should be assigned to the whole team, not just one person. Second, team-determined estimates may be more useful than individual estimates. Third, clarify the details of the point estimation process so that the team members can agree on the story understanding.

To estimate the

So let’s figure out what the units are.

There is no standard unit for estimating the size of a user story. The two most commonly used units are story points and ideal days, and there is no superior or inferior distinction between the two.

A story point is a unit used to measure the size, complexity, and number of user stories; that is, it is a benchmark against which other user stories can be estimated.

Story points

Story points measure the size and number of user stories. Story points are influenced by many factors, such as complexity and actual size. Stories don’t have to be big to look big.

Story points combine factors such as complexity and physical size to produce a comparative value, the goal of which is to compare stories.

For example: if creating a log card is 2 story points, searching a log card is 8 story points. This means that the search story is four times the size of the creation story, so that the size of other user stories can be compared, and so on.

An ideal day

Another way to estimate user stories is to use ideal days.

The ideal day is a common unit of estimation and represents the number of working days or person days needed to complete a story. But the ideal is different from the natural. In an ideal world, we might get something done, but in practice, we might be distracted by a variety of things and not be fully engaged in the work, resulting in a much longer time to complete it.

So, one of the important factors that can affect the ideal time is the possibility of misunderstanding.

Tell a popular story: You show your r&d colleague a story on Tuesday afternoon and ask him how old it is, and he says, two days. Yes, you can finish it by early Wednesday afternoon. He might wave his hand and say, no, no, bro, I’m going to finish what I’m doing this afternoon and tomorrow, and then, I might not start until Thursday, but since I’m not doing it all day, I might finish it sometime next Monday. You said, you told me it was a two-day story, so it should be done on Thursday. ‘I’m talking about two ideal days, not natural days,’ he said. ‘Please don’t directly correspond my ideal days to the calendar. You can’t play that way.’

See, this is how product owners and programmers fight (just kidding).

So, if there is a default consensus in the team that the ideal day as a story point is not misleading, the ideal day is probably better, otherwise the story point is better.

To estimate the

When estimating a user story, all team members participating in the estimation estimate the story.

If the team defines a story point as an ideal day, then the developer thinks about how many ideal days (story points) it will take to complete the story. If the team defines a story point as the complexity of the story, then the estimate is what the developer thinks the complexity of the story is.

Let’s say you have five team members, and three of them value the story at 3, and the other two, one at 5 and one at 2.

At this point, the estimates are likely to vary greatly, and the high and low estimates will need to be explained again, and so on, until the team agrees on the story estimates.

A more optimistic member might say, “To test this story, we need to create a mock database object, which might take a day, and we’re not sure if our standard compression algorithm works, so we might need to write a new algorithm that uses less memory.” A member with a lower rating would say, “I’m thinking about storing the information in an XML file, which is simpler than a database, but of course I’m not thinking about more data, which might be a problem.”

They then discuss the story for a few minutes and re-estimate it. In most cases, the second estimate is more or less the same, but if not, the process needs to be repeated.

The goal is to get a unified estimate for the story, so that everyone on the team can agree on the story point, which means that whoever wrote the user story agrees with the story point.

However, using this method is very time-consuming, and in practice, a relatively correct story point can be obtained directly from the simultaneous participation of all members in the discussion.

Using story points

A team is constantly honing and tweaking story points.

At the end of an iteration, the team counts the total story points completed.

For example, if a team completes 32 story points in one two-week iteration, there is a good chance that the next iteration will also complete 32 story points. We use “team rate” to represent the number of story points a team completes in an iteration.

How is team speed used?

If the team is going to start a new project, they estimate all the stories on the project, 300 story points, so before starting the first iteration, they plan to finish 30 points a week, which means they need 10 iterations to finish the project.

At the end of the first iteration, the team added up the number of story points actually completed, and they got 50 points instead of 30. If they had completed 50 points in each iteration, they would have needed six iterations to complete the project.

Should they use the measured 50 points as a rate plan?

Yes, but only if three conditions are met.

First, there were no abnormal times in this iteration, such as overtime, extra programmers, etc.

Second, estimates must be made in a consistent way. This ensures that iteration rate fluctuations are minimized.

Finally, the story of the first iteration must stand alone.

That’s all

If you have any questions, please leave a message and discuss 😊~