Let's dive into some techniques that I've found are useful when introducing Story Point estimations in teams.

1. Relative Measurement Benefits

Why should we do relative measurements? Isn't time estimation good enough?

Let's envision a scenario. We are working within a team of 7 people. We need to deliver a feature. The budget is set at 6 months of funding.

Each person estimates their own workload and we are off to the races. We work, we work and 3 months into the project, one of the software developers leaves.

The other software developer that is still part of the team, looks at the code and says that our goal can't be done in the amount of time that the other software developer estimated. First off all the code needs to be re-written. He also spots some estimation errors that their previous colleague has done.

How can we prevent such a scenario?

There are a few things that Agile Teams do:

• Shared code base: Everyone is allowed to touch any part of the code

• Team estimations, instead of individual estimations

• Crowd wisdom is stimulated via an array of methods; so everyone gets to speak and we ensure that optimistic and pessimistic views are heard

There are a few benefits that Agile Team Estimations give:

• We stop giving individual estimations and stop looking for individual responsibility

• We start focusing on team estimations and team delivery

• Long term planning becomes easier and faster to complete

• We stimulate crowd wisdom in discussing User Stories

• We give team members a chance to talk instead of listening to only one or two people holding the conversation hostage

• We decouple estimation from the person, so that we can stimulate shared product delivery thinking

  2. What is Relative Measurement

Relative measurement abstracts work into comparable items so that we can have a better understanding of what we are doing. There are multiple techniques for doing relative estimations: Story Points, T-Shirt Sizing, Bucket Sizing, Small/Large/Uncertain, etc.

Let's take an example:

There's a construction company doing a construction job. During this job, the workers of the company often need to move stones. These stones range from 10 kg, 50 kg, 75kg to 100 or even 200kg.

Because the company is at the beginning they don't have great tool to provide to their workers. Workers need to resort mostly to muscle.

There are two workers in the company. One worker is skinnier and shorter (1.7m, 60 kg) and the other one is taller and buffer (1.9m, 110 kg). They both need to do the work, however the taller, buffer guy does more.

If moving a 50 kg stone 1km, takes the skinnier guy 2 days, the buffer guy needs only half the time.

The time has changed, however the stone weight hasn't.

Relative estimations work on the same principle. Stories are similar to stones, we have heavier stones (bigger user stories) and lighter stones (smaller user stories).

3. Story points and Planning Poker

We estimate user stories by getting their weight in comparison to other user stories. Ideally these user stories meet the invest principle and they are vertical slices.

In order to estimate in story points we need something to start with. A reference. In order to help people weight it's often a good practice to have 3-6 references.

After we've decided on our references we simply estimate using planning poker. During the planning poker session we will discuss each story in just enough detail to estimate and get everyone on the same page.

4. Story Points vs Time

"Relative estimation is interesting, but in the end we still need to allocate time". That's exactly true. So how can we know how many story points we can take into an Iteration?

In the beginning we don't know. That's what happens in practice. The first 4 Iterations are calibration iterations. We know we won't get it right.

After 4 Iterations, we have an average velocity and the team can usually understand how much work they can actually take.

The ratio for story point to man day is a simple formula of: No. of Story Points delivered each sprint/Number of man days available.

So if a team delivers an average of 30 SP/Sprint and they have a number of 480 MD (6 people, 2 weeks), then 1SP = 16 MD of effort.