What are Story Points in Agile?

The story points are a measurement to estimate the work carried out through the implementation of agile frameworks like Scrum and eXtreme Programming.

Implementation of a user story is a difficult task to achieve. The team could face risks; complexities, etc. while the development process. This difficulty level is measured by the development team through the use of an abstract measure called the story point. Therefore, story points in agile are used as metrics in agile development. It tells the team about how difficult the implementation of the story is.

The product backlog grooming sessions perform the estimation of the story points which are then evaluated by the product development and the testing team. This is done in order to increase the efficiency of the sprint planning. The product backlog grooming is the rough estimation that checks:

• Whether the sprint plan is ready to be efficiently conducted.

• Is the information enough for completing the matters.

• Whether the sprint plan based on the user story is reasonable.

There are three main components in agile story point estimation:

Risk: for a particular item, the risks associated with it are vague demands, changes during the mid-process, and dependence on a third party.

Complexity: It represents the difficulty level of developing a feature.

Reception: It determines the familiarity of the feature with the team members and how monotonous certain tasks are within the development.

Incorporation of the three points allows the accurate planning of sprints including a cushion for uncertainty, issues related to better estimation, and avoidance of learning too heavily on time commitments.

Estimation of Story Points in Agile

Steps for estimation agile story points

Involvement of the developers, designers, testers, etc. is considered to be key factors while estimating agile story points. As every team member has different perspectives of carrying forward the work and delivering the product, effective collaboration is important. For example, change in any design doesn’t only require the efforts of a design team but also needs the involvement of the development as well as the QA department.

To start with the estimation of story points in agile, the team should have a baseline story that is not necessarily required to be small but which can be well resonated within the team. This is followed through the sizing of the stories based on the baseline story. With the help of the reference stories, points should be given to the story. Each story is assigned a point value.

Benefits of Sizing

The agile delivery team carries out the process of sizing which is easier to estimate. Through sizing

• The overview of the scope of work can be viewed.
• The size of work can be determined through multiple perspectives.
• Any false assumption can be rectified.
• Things that can’t be exact are cleared out.

Sizing is done considering the following:

• The amount of work to do
• The complexity of the work
• Risk or uncertainty in doing the work
• Time / Duration

The sprints can be more accurately planned by following the listed process: A three-step process to estimate story points are:

Use of Fibonacci sequence series.

• The traditional human day assessment has been replaced to estimate story points through the Fibonacci numbers i.e. 1, 2, 3, 5, 8, …

• A linear scale is not used as it offers items that are not differentiated enough to define an estimate. However, the Fibonacci series can estimate the minor jumps in a problem.

• Fibonacci series represents a sequence of numbers where the next number in the sequence is the sum of the preceding two numbers. To estimate story points in agile, the Fibonacci sequence is modified to 0.5, 1, 2, 3, 5, 8, 13, …

Determination of a matrix

• A baseline for each story point is determined.

• The baseline is included in the matrix as the value of 1. This is set as the standard for the least amount of risk, repetition, etc.

Planning poker Through the planning poker, the team agrees to the correct story point approximation for each item.

The working of planning poker is

• During the sprint planning, a set of cards is received by each developer and tester. The cards depict a Fibonacci series number.
• An item from the backlog table is selected out for questioning and clarifying the features of the items.
• At the end of the discussion, a card reflecting the estimate of the item is privately selected out by the tester and the developer.
• The cards are then revealed by the estimators. They move on to the net item if a consensus is met. For varying cards, the discussion is carried on by the leaders until a consensus arrives.

A completed matrix is useful for the estimators to use as a reference during the planning poker. This allows greater consistency across the tasks. Further, the maximum limit of the estimation is 13, if it is more than 13 then it is effective that the task should be broken down into smaller items. Also, if the task is estimated to be smaller than 1, then it is advisable to incorporate it into another task.

Another 8 steps estimation for successful estimation of story points in agile are:

Identifying the base stories

• One of the important steps to estimate story points in agile is to identify a base story that is used as a reference for relative sizing of the backlog.
• The baseline story is picked from an earlier story that was carried out by the development team or from a current product backlog.
• The understanding of the baseline story should be the same among every team member. In other words, there should be confidence in the team over the baseline story.

Discuss the requirements

• The details of the story have to be discussed and explanations related to the user story are to be provided by the Product Owner or a business analyst.

Jot down important things

• Any important things that are to be important should be jotted down.
• The scrum master best does this job during the ongoing discussions.

Important questions to be asked

A few questions are too important that the developing team has to ask themselves.

• Before starting on the design, what is necessary to be learned by the team members?
• What is the requirement of the code for the story? How much length is required and are there any similar codes written by the development team earlier.
• For acceptance by the customers, how much work is involved?
• Are there any external dependencies that the story has?
• Does anyone in the team have any expertise or experience working in the same story?
• Does the story have any simplicity or associated complexity either from the perspectives of business logic or from technical perspectives?
• How much certainty is there for getting the dependencies in time?

Points for relative comparison

• Relative points for comparison should be assigned to the story.
• The same number of points should be assigned to the story, i.e. 1, for stories which have the same amount of work as already sized stories.
• For more difficult stories, a proportionately higher value should be assigned.
• If the story is less complex due to the learning available from the previous story but almost similar to that story, a lower value is to be assigned.

A consensus is to be attained among the entire team as per the size of the story.

There should be a validation of the fact that there is an internal consistency among the stories.

It should be ensured at repeated intervals that all the 1’s are the same or all the 2’s match, etc.