Estimating in Scrum – Part 1

Estimating in a Scrum environment is much different than estimating traditional waterfall projects. In Scrum, story points are the key variable used when estimating. We will review what story points are and why they make sense in Scrum.

Story Points

In Scrum, user stories are estimated using Story Points, which are a measure of relative size and complexity. Story points are usually expressed according to a numerical range, such as the Fibonacci Sequence or according to a size range from X-Small to X-Large.

Why Story Points instead of Hours?

The inherent unknown in software development makes estimating in hours very challenging, especially if those estimates are provided by only one Subject Matter Expert (SME). Estimating how long it will take to develop a complex piece of software is not effective and if a new feature has never been developed before, the estimate will not be accurate due to the unknowns.

It is very challenging to estimate a project using absolute hours. We as humans are not very good at it. However – we are very good at estimating relative sizing. For example, we can all agree that an apple is larger than a blueberry. We can agree a watermelon is larger than an apple and so on.

Estimating in story points allows us to take time out of the equation, instead using relative sizes to represent the size and complexity of each feature or story. Over time, these story points will sum up to an average velocity per sprint and that average velocity is then used to forecast the remainder of your project. Based on empirical date gathered from prior sprints, the team can figure out how many sprints it will take to complete a given feature, release or the remainder of work left for the entire project.

Agile Estimation Approach

Estimating in Agile is based on a more collaborative partnership between the business users and development team. Changes to requirements are encouraged and considered normal and there are high levels of sharing of information.

Time-Boxing

In a Scrum environment, the duration of a Sprint is fixed anywhere from 1-4 weeks. Items that can be taken into a sprint and developed are selected and based on the capacity of the Scrum Team The team will agree on the amount of story points they can complete within that time box, which is to remain constant throughout the project.

Methods for sizing

There are several methods for sizing Story Points and we will look at 2 of them:

  1. Planning Poker
    • The most common technique for Scrum Teams
    • Team reviews each story, then everyone shows their cards with their number of story points.
    • The team reviews the number of story points. If there are variations in story points, the team will discuss their differences and agree on a number.
  2. Affinity Sizing
    • Draw a line on the wall from smallest to largest
    • Team reviews the stories then silently puts them on the wall relative to each other
    • Determine bucket values (points at the end)

Once the Scrum Team is used to estimating in story points, the estimation process will become easier and the team will begin to understand their average velocity, which can then be used to baseline future expectations.

In my follow-up post, Estimating In Scrum – Part 2, I will get into further details around how to use average velocity to predict future release delivery.

Do you like this article? Please share this post using the share buttons below!

Leave a Reply

Your email address will not be published. Required fields are marked *