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.

Advertisements

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.

      So, with that in mind, you have to be patient. The first step towards the business believing in Scrum and how it addresses estimation, is to get some general confidence in the process and the person who is responsible for it, such as the ScrumMaster or Agile coach. As a ScrumMaster, you do this by delivering results. In order to do this, you educate like a crazy person, holding training sessions for the entire department as well as 1-2-1 sessions. You drive teams to deliver quality code that doesn’t fall apart on release. It’s showing how Scrum is making a positive impact that will help you. If you read my blog about a really good sprint planning agenda, among other things, I have outlined how to get the teams to use get their heads around the concept of points and planning poker. I always start this challenge by getting them first to size previous stories or tasks the teams have worked on (so they are familiar) to help them. At first they will all have different ideas and their estimations will be completely different. This is to be expected., but they will get better with practice. You will also see that I start off with new teams by breaking down the stories into tasks, and then get the team to estimate each task in time. This way, you get the best of both worlds. You get the team thinking about points and complexity, but you also have the time element attached to each tasks (that makes up a story) to make sure your sprint is filled in accordance with your capacity.

      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

        Description: As a Business User 
                     I want to be able to retrieve my data from the system
                     So that I can run a Daily Report.
                     
        Team A estimate : 2 points for this story.
        Team B estimate : 5 points for this story.

        Both teams would only take 2 ideal days to complete the story. So taking a hypothetical situation where teams are “bidding for stories” team A win the bid because they’ve estimated 2 points, for no other reason. This is a totally invalid way of managing the project because both teams have estimated the same. As you have rightly “pointed” (hohoho) out points are a measure of complexity and not that of time to deliver.

        It is these sort of disperate figures that make managers wary, as in their head 1 point is equal to 1 day, it doesn’t seem how much you try to educate this particular concept can be very hard to shift (it is here patience
        is required).

        Oh an as an aside, I’ve also found challanges when I fill a sprint to say 60% capacity with “must haves” and they wonder what the 40% contingency is there four. “Can’t you add another 40% there”… Erm no what if they overrun?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s