Agile Story Points: Why and How to Use in Development Process

What is Agile?

Agile is the ability to create change and respond to it. It is a way to deal with an uncertain and turbulent environment and ultimately succeed in the app development process. The authors of the Agile Manifesto chose “Agile” as the name for this whole idea because the word epitomizes the adaptability and responsiveness to change that was so important to their approach

What is agile software development?

When you approach software development in a certain way, it’s usually helpful to live by those values and principles and use them to help you understand what’s right to do in your particular context. One thing that sets Agile apart from other software development approaches is the focus on the people doing the work and how they work together.

Solutions evolve through collaboration between self-organizing cross-functional teams using relevant practices for their context. In the Agile software development community, there is a lot of emphasis on collaboration and self-organization of teams.

This doesn’t mean that managers do not exist. This means that teams have the opportunity to figure out how they are going to act on their own. This means these commands are cross functional, and the teams don’t need to have specific roles, as when you put together a team you will make sure you have all the necessary skills in the team.

There is also a place for managers. Leaders make sure that team members have or are trained in the necessary skills. Managers create an environment that allows the team to succeed. Managers usually step back and let their team figure out how they’re going to ship products, but they step in when teams try and fail to fix problems.

When most teams and organizations get into agile development, they focus on techniques that help with collaboration and organization, and that’s great. However, there is another key set of techniques that are not as often followed but should be followed, which are ad hoc techniques that are directly related to software development and help your team deal with uncertainty. These methods are necessary and should not be neglected.

Story points in agile

What are story points? Story Points is a relative evaluation model native to Agile and Scrum. They evaluate product development efforts by referring to three development aspects:

• the amount of work required by the product
• the complexity of product features
• risks and uncertainties that could affect development

How to calculate story points in agile? At the start of the project evaluation, the developers choose the smallest and simplest user story that is in the product – for example, the registration user story – and rank it as a user story with 1 point. This is the base story: the user story that will be used to compare the difficulty. All other user stories will be assigned a certain amount of user story points based on how difficult they are to develop compared to the base story. This is how the user story estimation goes.

Story points and hours

Traditional software teams give estimates in a time format: days, weeks, months. However, a lot of agile teams have switched to Story Points. Story Points are units of measure for expressing an estimate of the total effort needed to fully realize a WIP item on a product or any other piece of work.

Teams assign sprint story points based on the complexity of the job, the amount of work, and the risk or uncertainty. Values are assigned to break down work more efficiently into smaller pieces so they can eliminate uncertainty.

Over time, this helps teams understand what they can accomplish in a given time frame and builds consensus and commitment to a solution. It may seem counter-intuitive, but this abstraction is actually useful as it forces the team to make tougher decisions about the complexity of the work.

Reasons to use Story Points

Story Points let you calculate the team’s speed and evaluate the work objectively.

The velocity of the team can be calculated

The velocity of your team is an important indicator that you simply cannot ignore. After calculating your team’s speed, you can visualize:

• the effectiveness of your Agile team
• the speed at which your Agile team is evolving 

Thus, you can better predict the schedule of your future project. Velocity (also called sprint velocity) shows the amount of work completed in each sprint. This is the total story points completed divided by the total number of sprints.

Estimate without specific time-commitments

How to estimate story points in a state of uncertainty? Not everything always goes according to plan, even in an Agile project. And when you use a time estimate, you are only giving an estimate of the time. You can spend more time on tasks you thought would be done in an instant, and vice versa. The bottom line is that it is difficult to estimate the exact amount of time needed to complete the technical task.

Because scoring is an agile evaluation method, it does not impose any special obligations. Instead, they give a relative estimate of the total effort put into the task. This will help reduce the unnecessary stress of meeting tight, unrealistic deadlines. Instead, you are left with a much smarter and more accurate estimate.

Story points aren’t subjective

Sometimes people disagree on how long a task in an Agile project will take. This often results in subjectivity in the use of time estimates. Therefore, this approach does not always give an accurate assessment. With Agile scoring, the entire team gets together and decides how much to assign to a user story.

Story point estimation

People are not very good at guessing how big something is in absolute terms, like hours or days. But we are surprisingly decent when it comes to evaluating something in relation to another.

For example, if you give a person two stacks of beans, they probably won’t be able to tell you how many beans each stack contains. However, they should be able to tell that one stack is about twice as large as the other.

Story Points include relative rating. These are dimensionless scales of measurement, the size of which depends on other tasks. Unlike clocks, which are based on fixed values, history points are based on arbitrary measurements.

Their sole purpose is to compare the task in size with your other tasks and see how much effort it takes to complete it. Agile projects prefer a points system because you don’t have to worry about how your “facts” compare to your “estimates”. Relative scores remind us that they are not intended to be used as a deadline.

Software estimation techniques 

Let’s talk about the agile estimation techniques in software development.

Planning poker

Everyone on the team receives a set of score cards. When the question is read, each engineer holds up a score card that he or she deems appropriate. The advantage of this method is discussion rather than compromise. Talking about why your estimates differ so much can reveal a misunderstanding of scale, which is helpful.

T-shirt sizes

The size of the T-shirt makes it easy for teams to associate values with issues without being overly scrutinized. Using t-shirt sizes (XS, S, M, L, XL) ensures that you don’t over-analyze things and is another reminder that your estimates cannot be equated with measures of time.

Have your team come up with a story score streak equal to XS, S, L, and so on. If something is XL, consider breaking it down into a number of smaller tasks. Once the score range is set, the T-shirt size is the quickest way to decide how difficult the challenges are and which ones can be prioritized in the upcoming sprint.

Triangulation

Triangulation is just a pretty word for “like-to-like”. Take your concerns and pick one that is specific. Let’s take one more, which is estimated at ten. And another one somewhere in between. You now have a basis for comparing the remaining tasks. Compare the rest of your tasks to these baselines: Is this problem bigger or smaller than my “problem”? Continue until all of your problems have been evaluated relatively.

How to estimate story points?

Use Fibonacci sequence numbers

There are two types of scales used to create evaluation matrices: the linear scale and the Fibonacci sequence. The Fibonacci sequence sprint planning is used when estimating absolute values is difficult, such as estimating the exact number of hours needed for a given task. Now, as tempting as it is to assign elements with a linear scale, this rarely works for plot points.

Why use Fibonacci for story points? The Fibonacci sequence is used when we are looking for a more accurate estimate of the complexity of a project. But keep in mind that you can still use a linear scale if you like; many do.

The Fibonacci sequence is a series of numbers, each of which is the sum of the two previous numbers: 0, 1, 1, 2, 3, 5, 8, 13, 21 and so on. For Agile, the sequence typically changes to 0.5, 1, 2, 3, 5, 8, 13, 21, and so on.

Create a story point estimation matrix

Thus, your baseline is included in the matrix as 1; this represents a story with the least risk, complexity and repetition. From there, you begin to build a story score matrix, or scorecard, as a way to measure effort more specifically, not just time. Once the first story point is established, you can populate the table with other stories related to that first one. More than one story can be associated with each value of a story element.

Play planning poker to decide on story points

Poker planning is a great way to agree with the team on the right approximation of the history points for each item in the backlog.

Poker Planner App in Slack

• During the sprint planning meeting, each developer receives a set of cards depicting the Fibonacci sequence.
• The backlog item is then brought to the table for discussion and clarification.
• Each developer and tester can privately select the card that they feel best represents their assessment of that element.
• Assessors reveal their cards at the same time, and once the entire team reaches consensus, we move on to the next piece of backlog.

It is useful to set a maximum limit, after which the tasks can be divided into smaller elements. Also if the task is less than 1 or 0.5, it can be included in another task. By the end of the poker of agile planning and estimation, the matrix should be completed, and tasks should be broken down into lines based on their story points.

How to convert story points to hours?

If you’re wondering how to convert size estimates into hours, let us wait until the first sprint is over so we can track team velocity as it progresses. Remember, Agile is all about iteration. As soon as the first sprint is done, we’ll know how many scrum story points a team can complete per sprint, which then allows us to forecast the team’s performance for the next sprint.

With all backlogs already estimated, we now know how many sprints it will take us to complete the project and convert those abstract units in real time.

Final thoughts

Although it includes math and Fibonacci series, the point method is not as complex as advanced calculus. However, effectively implementing many plot points can be challenging. We at Mobindustry use various story point estimation tools to accurately plan and estimate each stage of the development process.

If you want to build software for your business, don’t hesitate to contact us: we provide full support on any stage of software development and guarantee timely delivery on budget and according to your business goals and requirements.

Mobile app development

Web development

UX Strategy

Code Audit services