# The Power is in the Points

How hard is it to estimate how long something will take? The answer is very hard!  But why is this?  Well, there are a few key factors. Mainly, the problem with time is that in a short space of it anything can happen.  It is unpredictable. Estimating in time is risky.  Secondly, people aren’t actually very good at estimating how long things will take.  How many times have we heard “how long will that take?”, only to hear the reply “how long is a piece of string?”.  Sometimes tasks are so massive, we just cannot begin to get our heads around it.   People are, however, much better at measuring how complex a task is.

Let me explain…

If someone pointed at a messed up Rubik’s cube and asked me “Is that complex to solve?”.  Personally, I am really not very good at those things, so I’d be like “Err, YAH!”.  I don’t need to know much to know it is complex.   Complex doesn’t mean ‘hard’.  It’s not exactly ‘hard’, I mean it’s just moving some squares around, but its complex because it takes a lot of thought, and there are so many combinations to process as I move the pieces.

Now, if the same person then asked me “How long will it take you to solve that Rubik’s cube?” I would have absolutely no idea.

This is why in Scrum we measure complexity of work in story points as opposed to in time.  Once the team understands the concepts around points and planning poker, they get pretty good at measuring complexity.  It turns out it is a much more accurate measure of forecasting estimates than time alone ever will be, and this makes story points powerful.

## 3 thoughts on “The Power is in the Points”

1. I have run across a problem I believe to be common across most businesses who are just getting to grips with points. And that is the management need to relate 1 point to a physical unit of time for example 1 point is equal to one ideal day. This makes a mockery of the point system as points are relative to teams and 1 teams point may be another teams 4 points, how have you solved the need by management to have time schedules based upon team estimation so they can report back to the business estimated costs. I have yet to find a way to solve this issue.

• In my experience, for a transitioning organisation, you have to acknowledge and accept that expecting management or even teams to give up on the only thing they know i.e. waterfall/ghantt charts, time estimations etc is not a given just because they have hired a ScrumMaster. You need to be patient with them. The analogy I use is thus; if you were to go to live in another culture, say SE Asia, despite the fact you may have prepared yourself for the transition, you’re not going to walk out of the airport and behave as if you have lived there all your life. You will still need time to adjust to the culture, the customs, the climate etc. There will be uncertainty, and you will embark upon a process of learning and familiarisation before you can start to feel ‘at home’. To me, it is no different in an organisation’s Agile transition. There are a lot of cultural and practical changes that come with this shift, and these changes take time.

After a while, the teams get better at estimating in points, and their velocity evens out (given the teams are left consistent throughout the sprints). After quite a few sprints, I would say at least 6, the team are working better together, they are more knowledgeable of various systems and are more confident in their abilities not just to code or test, but to estimate. They are also more confident in YOU, the ScrumMaster, and your abilities to guide them through this weird and wonderful Agile world. When you can see the teams are at a stable state, you can then progress to remove the time element from the tasks and just fill the sprint based on previous velocity measures. I would never attempt to make any estimates to the business in terms of forecasting unless I was confident the teams’ velocity had stabilised. Otherwise you risk feeding the business inaccurate information, and if it all goes wrong they will blame you and Scrum…If high level estimates need to be added to PBI’s for a project in order to get a high level estimation as to its completion, this must be done by a developer. Not a BA or a PM. Get it from the horse’s mouth, from someone who knows the system. However, whenever a developer does any high level estimation, you always reiterate to whoever has requested it that this is an ESTIMATION based on the information presented in the stories at that snapshot in time. If you have been a good ScrumMaster and have educated people to a good level, they should understand where you are coming from. They will understand that and estimate based on complexity (points) is more accurate that estimating in time, which at the end of the day, is what they want. They understand that this figure may change. It is an estimate, called such because it is just that. It will always be a challenge, but investing copious amounts of energy in championing Scrum and making sure you promote EVERY single success, change will happen, slowly but surely.

So, the key thing is to first build the foundation of trusting Scrum within the business. Get some results like a successful release, or a retrospective showing happy teams to get the business to believe in Scrum, or even how great the Scrum Board looks half way through a sprint. Then you are in a stronger position to challenge them if they don’t want to acknowledge your estimates or how you have established it.

• I agree with pretty much everything you say here especially the following salient points:

1) you have to be patient.
2) you educate like a crazy person
3) It’s showing how Scrum is making a positive impact that will help you
4) developers will get better at estimation over time
5) the teams will get better at estimating in points
6) planning poke is a good tool
7) Time estimates for high level to come from a developer.

The reason for my enquiry is because when you have multiple scrum teams reporting back to perhaps one line manager who is old school waterfall (and most are) they will always try to compare Team A to Team B and sometimes wonder why Team A would estimate the same work requiring the same effort in a different amount of points.  I’ve always found it quite difficult to get over to people that points in one team are not neccesarily comparable to that of anothers, as its a relative scale based on many different factors, team size, team experience, sun spots .. that sort of thing.

For example

Story A :
Level : Medium