Estimating in Story Points

When starting out with agile, some teams struggle with Estimation. Here, Markia Zep builds up estimation from scratch!

In recent years Story Points have become a unit of measure widely used in software development to establish the volume and related effort to deliver a working increment of a software product. The shift to estimating work in Story Points has been a struggle since the concept was introduced and various articles available online attempt to explain the “what”, the “why” and “how” of the estimation. Readers can choose any of them and it will probably be correct if it leads to common agreement and understanding of the purpose and meaning of this style of estimation.

What are Story Points?

Story Point is a unit of measure that allows the team to agree on the volume and complexity of work planned. It is expressed in the “modified Fibonacci Sequence1”. The difference is a cut-off in precision. The Fibonacci number is a sequence where the next number is a sum of the two previous numbers and so accordingly to Fibonacci the sequence goes:
0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144…

On the side of software development, this sequence has been adopted (with some variations) as follows:
1, 2, 3, 5, 8, 13, 20, 40, 100

The reason for the change is to remove the impression that beyond “13” we can estimate with any kind of precision. Additionally, we are letting our stakeholders know that these points are not related to days or hours and thus 21, doesn’t mean we will hand over working software in 21 days.

Why estimate in Story Points?

Story Points have been applied to mitigate one, very important aspect of software development - it is knowledge work. Many academics have looked into the productivity of a human related to cognitive work. Some research will point out that during the 8h working day, a person performing work that requires problem-solving and thinking, can only focus for 6 hours.

What this estimation doesn’t include is the fact that humans need to have comfort breaks, eat food and are constantly distracted. Moreover, scientists have also proven that when our work requires cognitive effort, every distraction costs us 20% of effectiveness before we regain the focus we have had before we
were distracted!

Knowledge work that requires any cognitive effort is difficult to calculate. Humans are difficult to predict. Writing and troubleshooting software was never work that could be calculated and predicted effectively by Project Managers beyond release 1.0. Story Points have been adopted because the unit of measure is driven by agreement. We rely on our Agile Teams to tell us what the Story Points mean for them when it comes to the type of work they are doing as well as the complexity they are dealing with.

How to Start Using Story Points

The hardest part is to help the team divorce Story Points from the units of time as quickly as possible. Unit of time is often used to start a team off and help them find the smallest piece of work but the One in our sequence is not a day or an hour. One doesn’t become two if someone less experienced is working on it. One doesn’t turn to 5 if testing is more effort than development. It all starts with “one”

The simplest way to start is for the team to select a User Story that has the smallest amount of development and smallest amount of testing required to deploy it (not necessarily to live). The Story in question needs to be well written and so it needs well-written acceptance criteria, it needs to be discussed by the whole team and the whole team needs to agree that this is indeed well understood piece of work and that it can be defined as the smallest they have come across as a team.  From this day on - this Story will become your “one” and your reference point for all other estimation.

Images Right: tables to the left show an example guide that you can, and should, edit to suit your team

Other pieces of work that will be twice as big will become two. Three times as big three. Four times as big will become 5… etc. all the way up to 13. That seemingly unlucky number is the last in our modified sequence that can suggest a level of precision. It is a popular practice for teams to use the number 13 as a sign that the work is large and volume and possibly complexity, and to gain a better understanding, it needs to be split into smaller deliverables. There are several things to remember when using Story Points for estimation:

  • Team shouldn’t re-set the baseline. If later on in time the team will find an item of work that developed, tested and deployed is much simpler and smaller in volume than the One already established, it will still be one (not half, no 0.2). The first one found is still going to be the reference point. 
  • Team shouldn’t change Story Points if the work is going to be performed by someone who’s less  experienced. The established volume and complexity remains the same. It will just take longer to deliver. We don’t change the estimation.
  • Team shouldn’t split development and testing.  In teams where testing and development are handled by separate team members, very often the work items are split into development and test and estimated separately. While this might be necessary based on the organizational constraints, the ultimate goal is to finish increment of work. We can only finish an increment of software if it is working. We cannot claim it’s working if it is not tested. And so it’s the Agile Team’s responsibility to create and estimate stories that can be considered “done” and thus - include testing and the development efforts

Working with New Team Members

Occasionally an established team will have an addition of one or more team members. They might be inexperienced and so the Story Point estimation topic needs to be revisited by the team’s Scrum Master to explain the mechanics and help the team plan Iterations reliably.  It is natural, for the team to jump to conclusion that if an inexperienced team member will work on a story, then this person’s estimation will be larger. However, what we need to remember is that the new team member takes into consideration not the Volume and the Complexity, but the gap in their experience. Their estimation is based on “unknowns”. So should we adjust the points on stories that this new team member will work on? 

Perhaps a better approach would be to engage the team members in the Pair Working activity. That way, the experienced team member can take the Story that the team has agreed is the baseline estimated as One (in Story Points) and demonstrate to the new team member why this particular Story is “1” in both Volume and Complexity.  Having gained this understanding, the new team member will be able to either estimate the Stories relative to the One or abstain from the vote if the Story is not well understood (this is the reason most of the Planning Poker packs have a card with a question mark on them).

What does it mean for the team’s Iteration Planning?

The biggest gain from baselining Story Points for the whole team is the ability of Scrum Master to observe the team’s growth and experience in the work they are dealing with. Simply put, an inexperienced team will take longer to deliver during an iteration five Stories estimated as one point when they are just starting up. As learn and gain new knowledge, they will be able to go through more stories. Looking at the velocity metric we will then observe that an average velocity per Iteration will grow over time. Bearing this in mind, it is natural to expect that adding new team members will mean that, in the beginning, the team’s velocity will take a hit (which in itself is an important context for the metric). The inexperienced team members will take longer to deliver a Story estimated as One. The experienced team members will also spend more time delivering their work because they might be Pair Working with new team members and spend time teaching them. All of these should be taken into consideration when planning Iterations. 

So how long should a new team member engage in Pair Working? This will depend on various factors. If the type of work that the team is dealing with is constant and familiar to them, it might be that the new team member will only need to spend the first iteration Pair Working with other team members to understand the range of Volume and Complexity of work the team is dealing with. On the other hand, we are dealing with the individual’s level of skill, knowledge and ability to learn. A practical approach is required. It is ok to rely on the more experienced team member for advice when planning a new iteration. The experienced team member might be able to identify a Story that the new team member should be able to work on and deliver based on what they have learnt.  


In conclusion - It is not recommended that the team adjusts the Story Points based on the lack of experience of the new team members. Once the team agrees on what a One Story Point piece of work means in terms of Volume and Complexity, this needs to be explained to the new team members so their progress can be visible.

Contact Us