Story of Story Points

"Let's use Story Points


We are following agile now

Yayy.. story points!

How many hours these epics, stories will take?

But we are using story points..

Yeah, but we still need to plan. Hours are better for that. 1 SP - 5 hours. ok?"

Heard this story of story points many times.


It is important to understand why do we need Story Points? Is it mandatory for being agile? Are hours prohibited?

The key motive for story points or hours is that we need to estimate the work, so we can tell what can be achieved in given time. Hence, we try to estimate. Hours are used since long because time is easy measure for us, and we can quantify easily, 'accurately'.

However, it become challenging when we found that even after best try, it is hard to estimate the time. It is more and more true in non-mechanical activities, where outcome depends on many intangible factors like skills, information available, mood, motivation, environment and so on.

If estimates can not be done accurately, then why to estimate. Let us just keep working and ship whatever is done. And this is also one of the philosophy and may work in specific setup. However, most still need a roadmap with understanding of possibilities which feed into overall plan of business.

'Possibility' is the key word here. We gradually understood that accurate estimate is not semantically and practically right. However, we can try to have best guess based on available information, which reflects the possibilities. As long as, we accept this fact, that we are talking about possibilities, hours or story points or tshirt size or anything else works.

If we consider this, ultimately, it boils down to 'common understanding'. Common understanding that when we are estimating, we are talking about possibility. If we all are good with this, any unit can be used for estimation.

Building up on this understanding, let us talk about common understanding. How easy or difficult is it to have common understanding with many people of different skills set, experiences, background, motives, different stakes and responsibilities. There are so many psychological factors, which makes it difficult to have this common understanding, more so if unit of measurement (hours) is traditionally used for accurate outcome. As soon as, we say x hours, it triggers a mental understanding of accurate number and then we want to see that getting materialized. People usually understand that estimates are just estimates. But as soon as we attach it with Hours kind of definitive measure, it build up expectations of accuracy. This is the key challenge to address.

To address above challenge, efforts were made to bring some kind of abstraction. That's where Story points help. With story point estimation,

  • We are not estimating individual story, rather we are estimating 'stories' relatively in respect of each other. It removes the feeling of accuracy, being relative.
  • We are separating amount of work and efforts required to complete this work. Story points reflects amount of work (considering complexities/risk etc) Which helps in having common understanding faster. It is easy to agree on amount of work, than for efforts required to complete it.
  • Estimates are given by team, for team. These does not reflects any individual capacity. Hence we are focused more on team capability, rather than individual stars.

Let us take an example

Team A is based in Singapore, have 5 team members. Team does outdoor activities every month, which is relay cycling. First month, they choose from office to East Coast park. Because whole team is familiar with area, it was easy to settle on distance estimation from office to park (assuming no google map :) ), say x km. Everyone agrees after some discussions, that it feels like x km, normal route with good roads from office.

How much distance each can cover depends on individual cycling speed, practice, fitness, cyclic condition etc. Hence, distance covered by each team member can vary a lot. Team agrees that everyone will cycle for a given time. Distance can vary based on individual capacity.

First month, member A cycles 'a' km, B covers 'b' and so on. Finally team covers y km in decided time, which is equal to x-n, few km less than actual park distance.

Next month, they went again for same route. As they already have experience of this route, they knew in advance that how much they can cover. However, when they cycled, weather was nice and hence members were able to cover few more km due to pleasant environment, ie y+n.

Next month, same route, they were able to cover whole x km. Because team got experienced about route, knows all the turns and hurdles, and members were also getting more skilled in cycling.

Following month, they picked a new target. They agree on distanced which was Y km. This time, as they are well aware about team capacity, so they set y-x as first month target. And they were able to meet that.

Next month, they went again with same target. But they were able to cover lesser this time, because one team member was not in good mood and hence was cycling slow.

After cycling for 5-6 months, now they know how much they can cycle together in relay. They know each team members usual capacity, and capability to manage hurdles. They also consider other moving factors while calculating like mood, weather, road conditions etc. And accepted that these can again change anytime to either side.

In this story, distance/complexities from office to East Coast park is Story Points. Which is an estimate of total work, not the time needed to cover that. Total time to cycle is the sprint duration, which is fixed based on whatever team thinks appropriate. The average distance covered by team over the months is the velocity of the team.

Overall team knows their capacity now (velocity) and can try to estimate any new target based on this understanding in much better way. But they are still open for variation as there are always many moving factors.

Team B is based in USA. They are also doing similar relay cycling. They interact with Team A once in a while to discuss. To their surprise, they were covering much lesser distance than Singapore team. On further discussion, they found it is because they have many new members in team who just started cycling and weather is also very cold which slows down the pace.

Finally both understand and agree, that velocity of Team A and B will be different as team, experience, weather, geography is different.

Next month, Team Manager comes with a new opportunity of cycling in a place, new to both the teams. Both teams explored about place for whatever information they could get. They give their estimates of distance/complexity/risk ie story points based on understanding of place by each team. Estimates were different from both the teams, as their understanding and assumptions of new place, and understanding of story point in each team is also different. Everyone also agrees that as it is new place, there can be some surprises which may impact the velocity.

As estimates i.e story points were different from both teams, teams decided to pick items one by one, and start delivering it. If any of the team finish before their estimation, it can always picks more. Ultimately goal is to complete the work as Team, while appreciating factor that every team has different understanding of story points and velocity also.

But how does it work in overall planning and budgeting for management: Size of team i.e. capacity is fixed. Manager knows the velocity of team. Any new work is estimated by team as story points, which divided by velocity gives idea of tentative timeline.

Isn't it just tentative, as sprint points are telling the amount of work and not the time required. Velocity is just the average of amount of work delivered by team. And that's right. Estimates are meant to be tentative, even if we use hours.

Why can't we use hours then

  • Relative vs Absolute: Story points are estimation of amount/complexity/risk of work, and is relative to other work items. While Hours is a wish to have absolute value for time required to complete it, in an effort to bring certainty in estimates.
  • Acceptance of Diversity, Safe Environment: Velocity reflects the team's capacity to deliver the work. While hours trigger the judgement of individual capacity to deliver the work. Story points, which are estimates at team level, accepts inherently that people have different skill set, and experience which will result in different amount of work. Story point and Velocity at team level provides an abstraction over this, and creates a safe environment for team while accepting the diversity.
  • Trust in People over Tracking: Story pointing and velocity based planning also strengthen trust in team, people. Where we believe that team has best intention to deliver and will keep picking work as they complete the last one. Hours triggers the usual tracking routine, with possibility of going into how many hours were committed, how many have been consumed, who took more time and why. It is vicious loop, once we slip in that. On other side, trust empowers and motivate people to deliver more than what one can think.

Does that mean that we should not use hours at all - We should leave it to team. If team is feeling more comfortable talking in term of hours as it can give them more concrete data at least for immediate work in hand, they can choose to talk in hours.; However, for distant roadmap, hours always fail the planner. Hence it is better to go with abstract units, which can inherently reflects the uncertainty.

Are story points mandatory for Agile - No. Agile does not talk about estimation methodology. Agile is philosophy, mindset about doing the work and how team can operates to maximize the outcome. It is not a framework or set of procedures to follow.

There are discussions around #noestimation too. If we combine above points, it is on similar lines where we build a good team, and then trust team to deliver, and don't spend time on estimates which always changes. Rather we increase the frequency of re-planning and adopting to new realities. Team delivers more this way, rather than by giving estimates, try to stick to estimates by working overtime or vice versa, and being questioned later with a possible dent on motivation.

In agile, (customer) Story matters over anything else, and a trusted team is what it takes to build the (success) Story.

What is your story of story points or 'Being Agile'..

Few good references:



People who read this post also read :


Post a Comment