Agile Development and Story Points

Agile development team at a kanban board.

Introduction to Agile Development and Story Points

To be agile, both the team and the client needs to be very responsive. The whole idea behind agile is to make sure that teams can adapt quickly. However, if a client isn’t responsive, the team cannot adapt, because a client ultimately has to sign-off on work. A client can also have a product owner. Someone that is dedicated to the project from the client’s side and can sign off on things and make important calls.

Story points act as a measurement unit, expressing the overall effort that’s required to implement work in a product backlog fully. A backlog is a set of tickets that haven’t been handled by a development team yet. It’s practically a wishlist of things that a client still wants to implement on their project.

Story points are measured in complexity and not time estimates. The main reason why we measure like this is that time estimates might change, depending on circumstances.

A Real-Life Agile Development Scenario

Meet Jimmy. Jimmy is a senior software engineer and Top Software International. He develops backend systems daily. Jimmy has a client Sarah. She’s looking for a new ticketing system to manage walk-ins at her shop. Sarah wants to know how much time would be required to develop such a system and what the cost would be.

Walk-in clients are Sarah’s store.

Jimmy has done this kind of development many times and is confident it won’t take longer than a week. However, what Jimmy didn’t keep in mind when giving this estimate, was that his boss had already arranged a workshop for the next week, which he needs to attend. Jimmy’s estimate is, therefore, instantly doubled. Although the amount of work might not have changed, the time to delivery did. That is why we make use of story-points when doing estimates and not hours. Rather than estimating the time required, we estimate complexity. Estimating complexity won’t change, irrespective of circumstances. If Jimmy had done an estimate in story-points, it wouldn’t change, even though he’s going to a workshop for the next week.

So, you might ask, if one does its estimates in story points and not hours, how would we ever know the duration of a project? Well, this is where velocity comes into play. Each team continuously measure the number of story points that they’re able to deliver. Story points are delivered in sprints, usually one to two weeks. During a sprint, teams plan a certain amount of work—each piece of work in sized in story points. Since a team knows its velocity (the number of story points/given time), they know how much work to commit for the sprint.

Suppose that a team has a current velocity of 20 story points/week with a single developer in the team. Sarah approaches the team for her ticketing project. Before an estimate is given to Sarah, they perform a planning session to map out all the complexities and create their Agile stories and epics. Once these tickets have been created, they’re sized during a planning poker session. In this session, each team member has to part-take in the sizing of each piece of work. Sizing in this ways makes sure that most complexities are taken into account.

After sizing the ticketing system for Sarah, the total is 40 story points. Since Sarah is willing to pay only for a single developer, and that developer has a velocity of 20 story points/week, we know that the project should take around 2 weeks to complete.

Why Agile Development?

Agile development teams can adapt quickly to change. When a client requests a change, they can rapidly implement that change without a waterfall of work rushing down on the client.

In the waterfall approach of software development, a client requests a certain amount of functionality from a development team. A spec is created, and the development starts. After 3-months, the team gets back to the client with the completed project. A massive amount of functionality is dumped onto the client and makes it very difficult to test and debug. It’s the first time the client sees everything in working order and realises, but this isn’t what I wanted.

Think of it as building a house. Your house is built, and you visit that house regularly to see progress. If you were to visit the house only after construction had been completed, chances are, you would be unhappy about multiple things. For this same reason, agile teams show their client progress as they develop in one or two-week sprints. These sessions happen as daily standups. This process is demanding and requires client availability. However, the result is well worth the extra effort.

Story Points in Agile Development

Method Behind Story Point Sizing

Each software team should decide what the size of their maximum story point should be. SwiftCom’s team works from 0,5 – 8. Once a story is bigger than 13 story points, we break it down into smaller stories. The increments we follow is based on the Fibonacci Sequence. This sequence already takes all-natural disaster into account. The sequence is present in so many natural living and growing things like flowers, shells or event to make sure waves never hit the beach at the same time. The sequence also takes into account things like disruptions or scope in the software development industry. Therefore, when sizing something in story points using the Fibonacci, your estimates will be extremely accurate.

Also, be sure to understand that raw story point values are not of importance. Sizing relative to empirical stories matters most. A story of 0.5 is half the work of 1 and 2 is double the work of 1. The sizing is, therefore, exponential in complexity.

What is a story point?

Here’s our best effort at explaining it. Imagine you have a room full of things you would like to move. You start off by removing a single chair from the room. Many objects remain to be removed. However, now you have to estimate the amount of time required to remove all the objects from the room. Based on the effort required to move the chair, how difficult would it be to remove the rest? If a chair were to be a 0.5, how difficult would it be to remove a whole table full of things?

  1. You start by analysing complexity.
  2. Do you have to remove the legs?
  3. How many things are on top of the table?
  4. Is a 2nd person required?

Once you’ve determined this, start sizing the removal of the table. Note, a sample of one might not be enough to size the table correctly. The table might be seen as your most complicated task to compete, so size it as you most significant possible value. In time, as you keep comparing the complexity of work to the past projects, you start building empirical data, and your sizing becomes more accurate.

When sizing story points, a team’s sizes should at least include the following four things:

  1. The amount of work to be done.
  2. The complexity involved in each story.
  3. Possible risk or uncertainty around the project.
  4. Definition of done.


To wrap it up nicely. Agile can be fantastic for your team. SwiftCom’s team has made fantastic progress by following the agile methodology. We’ve cut project development time drastically. However, it’s also worth noting that some clients aren’t as available as others. This can cause frustration in the team as work cannot move to done until the client has signed off. Additional charges might also be required, putting a story back into the process.