How to Use Story Points for Agile Software Development

When it comes to agile software development, there’s a bit of a paradox. On one hand, the essence of the agile methodologies approach is to make all stages of the software development cycle as transparent as possible for all parties involved. On the other hand, it’s often difficult for agile developers to accurately estimate the amount of time it’ll take to finish the project, so due dates might seem somewhat mysterious.

Indeed, when working in a highly dynamic environment, the traditional day/hour approach to project estimation doesn’t work. But don’t worry, agile software projects can be estimated accurately if the right approach is used. Let’s look at the Story Point Approach — or how to make estimations in the agile practices.

Wild guesses vs. Accurate predictions

Planning and estimating is essential to ensure the success of a software development project, yet many teams still struggle to meet deadlines. The reason is simple — at the very beginning of a new project, no one knows for sure how much time is needed to implement each feature.

We will not discuss whether or not estimation process is absolutely necessary for agile development projects. The decision fully rests on the team: many successful teams across the world work effectively even without estimates. Still, estimation is a common concern for project managers, so we’ll show you a good approach for accurately estimating agile projects.

Why estimate software development?

Estimation is helpful for:

• planning a budget
• allocating resources
• coordinating different teams’ actions
• determining priority order
• identifying complexities and uncertainties

Estimation tips

• Be careful not to spend too much time on the estimation process. At the very early stages of the project it might be difficult to see the whole picture, so don’t bother trying to come up with a 100% accurate estimation. New data will sure appear once you jump to development phase and you will most likely need to make adjustments as you go along — and that’s OK.
• Let the team members in charge do estimations. Estimations done by third-party experts and other outsiders (no matter how experienced they are) could end up being irrelevant to those who will actually be doing the work.
• Re-estimate stories on a regular basis. This will give you a chance to incorporate additional information since many things might change as the project progresses.

The basics of  an agile method in project estimation

The agile software development concept of estimation is based on the assumption that relying on empirical data is safer than on wishful thinking. In other words, estimation helps a team to make accurate predictions based on what they’ve done in the past. To give you a better understanding of this approach, let me introduce some key terms.

User stories

User stories are short, one-sentence descriptions that state project requirements. Something the team can show the customer or any party involved to explain what they are working on at the moment.

The initial set of high-level (epic) user stories is created together with the agile software development team right after the customer has delivered project requirements. Later these stories will be divided into fine-grained ones, so several user stories could be complete in one iteration.

User stories should cover all aspects of the project including design, prototyping, and research, so the customer could see the whole iceberg of the work ahead, not just its tip.

A working pattern for a user story might be:

As a <role>, I want to <goal> to achieve <value for the customer>
E.g. As an administrator, I want to perform user management so that I can maintain the user database.

All user stories are scheduled into iteration / release / product backlogs depending on the priorities.

Story points

Story point is an abstract unit agile software developers use to estimate the work required to get the story done. It covers all of the project’s stages: design, development, documentation, and testing. Sometimes it is called a measure of complexity.

Typically, humans are not very good at estimating things absolutely but are pretty good at estimating things relatively: this looks bigger than that. The agile approach just uses it to our advantage by sizing stories relative to each other using story points.

Thus, giving 2 points to one story and 1 to another, a developer declares that implementing one story is twice as hard as the other. However, this doesn’t necessarily mean that implementing the first task requires twice as many hours as the second.

Velocity

Velocity is the team’s productivity, expressed in terms of story points or user stories themselves since some teams refuse to estimate stories in points and work with stories directly. It is the number of story points (or stories) a software development team can deliver in an iteration.

If the project is already running, you can estimate the velocity based on yesterday’s weather principle — by averaging the velocity of the last iterations.

If you’re starting a new project and don’t have any velocity data yet, you can use hypothetical data. The team chooses several stories and makes an assumption how many of these stories can be finished in one iteration. Then, an average number of points is calculated for each iteration and based on it — the estimated speed.

Knowing the velocity allows us to count days and set deadlines. Even though this may resemble the day/hour approach, it’s not, since the main emphasis is not on fixed dates, but rather on the amount of work in each iteration.

Now, when the stage is all set up, here’s how you make an agile software development plan:

• Step 0. Discuss project requirements with a product owner.
• Step 1. Create a list of epic user stories.
• Step 2. Break epic stories to fine-grained stories.
• Step 3. Group stories and size them up.
• Step 4. Prioritize each story.
• Step 5. Estimate your team’s velocity.

Why use points?

When it comes to agile driven development, many teams believe that point approach shows better results than time approach. Here are the reasons:

• Lack of data on the early stages
  Since you don’t know how much work you really have for a story, putting any day/hour figures will be like sticking a finger in the air. Choosing unit stories, on the other hand, and determining the level of complexity sounds more reasonable since focused on size it will stay the same no matter what.
• Different ideal times
  So many developers, so many opinions about the ideal time. The ideal time for a task may vary considerably from one person to another. So if the one who does estimation is not the one doing the work, most likely the estimate would be too optimistic or pessimistic.
• Ideal time vs. Elapsed time
  So often we forget that the ideal time is not the elapsed time, which covers the whole time spent on the story, including all the routine of an ordinary workday such as meetings, phone calls, coffee breaks, chats, etc.

The Story Point approach is one of the most popular approaches used by agile software development teams today. However, it’s not the only option for evaluating agile projects. Possibilities are endless. Some teams, for example, do not use points at all, saying that the further in future one estimates, the less accurate he/she gets. In this article, our goal was just to give you a poke in the right direction, to show that estimation of agile projects is not scary but rather an effective software development methodology you can use together with your team.