As soon as you start looking at a backlog of tickets for a development team in an agile setting, you’ll start seeing and hearing numbers discussed. 1 point this, 8 points that, that projects huge, at least 50 points.
So why all the numbers? Why do they get so big and why are we talking about them in the first place?
Story points aren’t required in the basics of Agile. They are a mechanism of tracking work in Agile flavours such as Scrum. As Scrum tends to be the most popular model for development teams out in the world, so points tend to percolate whether your team does Scrum or not.
So, why points?
Development work is inherently unpredictable. There are massive amounts of literature summarising these 5 words, and why its the case.
When working in business this is a problem – try telling a member of an exec team that you can’t tell them when their project will be done by because it’s unpredictable.
Points, and the broader structure around Scrum, aims to answer this problem by reposing it – if the work’s unpredictable, lets talk about how unpredictable it is. We measure that unpredictability in points.
What’s the point?
All starts to sound a bit esoteric after a while doesn’t it? We can’t quantify it so lets quantify it with points. Don’t let it get too tangled up to start with.
Let’s say that you want to change the colour of a button on a website form. For the purposes of this, let’s assume that the colour can be changed just for this button without impacting anything else (this may or may not be the case, depending on how the website was built).
Changing the colour of an otherwise completely isolated button is one of the easier things which can be done in software engineering – change the hex colour code associated with the button being one of the solutions.
If this is the smallest thing your team can do, consider what comes with this work – unless your code base has a very simplistic process, changes will need to be reviewed by other developers, be reviewed by testers, be put on a staging website; time will need to be found to publish the code to production, the work needs to be published and post live checks might all need to be done. This to remember than development is rarely a fast process.
This small piece of development might be given a 1 point estimate – it’s the smallest thing we can think of, so we give it the smallest whole number. Try to avoid half points – you’ll get stuck doing fractions which takes time. There’s no such thing as no effort for a change, so 0 points isn’t a thing.
From there, think of the next biggest thing which might be done – 2 points. Then the next biggest – 3 points. The one after that gets 5 points, then 8, 13, 21. Those of you who like numbers might recognise a Fibonacci sequence – take the previous 2 numbers and add them together to get the next.
Depending on your team, you might keep going with the fibonacci sequence – 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 etc. or you might round out the numbers at 30, 50, 100 points or similar. Rounder numbers tend to be easier to think about and communicate with, more on that later.
Sounds lovely, I guess, why do we do it though?
Quantifying Predictability
To put it simply, development isn’t an easy activity. Anything that can go wrong will eventually go wrong, and that generally means that planning timelines on tasks will generally not work.
So, pick up a piece of work that you think will take a week to complete – over many pieces of work you think will be a week you might find that you average out to a week, but any individual piece of work is unlikely to hit that estimate.
Whilst for general planning that might sound annoying, it’s an extra problem for communicating to executives, project managers and other people who are planning around the things you’re delivering. In a retail space, you have not only people sharing your office space with revenue targets to consider, but a network of customer facing staff who need training to consider, timing is everything in this sort of setting.
Whilst you can’t (and shouldn’t) try and give a tight timeframe on a specific piece of work your developers aren’t almost finished with, you can give a long view to interested parties.
Over the course of several sprints you’ll generate an average number of points your team gets through. This can, and should, fluctuate over time – 5 points in one sprint won’t take the same amount of time as a different 5 points in the next sprint. After 3 or 4 sprints though you’ll have an average which should keep relatively steady over time, assuming some consistencies in ticket quality, team make up, area of focus etc.
That means that whilst your individual deliverables are difficult to estimate time on, you can give a sense of the amount of time your entire backlog of un-started work should take by dividing total number of points in your backlog by sprint delivery average.
This is the only way a pure Scrum system has to provide long-term predictability of delivery. It’s also why we use Fibonacci numbers – big steps between numbers are vital to demonstrate the unpredictability in time and investment that pieces of work can equate to.
Consider our button colour change – we think we understand everything there is to know about this, hence it gets 1 point of effort. Maybe it’ll be bigger, but it’s unlikely to be enormous. A larger piece of work at, say, 8 points is much more likely to take more or less time than people think. You might think it’s a week to deliver when you get to planning, bit it might be 3 days, it might turn out to be 2 weeks, depending on the item, the developers and unexpected outcomes.
Your increase in points doesn’t equate to time, your sprint picks up the number of hours your team thinks it can get through. Big points allow you to take the long view on your backlog and roadmap – the bigger the points, the more wiggle room you get in your sprint planning against your velocity.
Planning in this way should absorb some of the unpredictability in delivering a given project because your next point step is by nature big enough to allow for things to go wrong with delivery.
Buckets filled with water, not sand
Being strict, and just a little pesimistic, is vital to pointing work – both for you and your development team. The best, and common, metaphor is considering your point brackets as buckets of a set volume.
You have a 3 litre bucket, a 5 litre bucket and an 8 litre bucket. If you can’t fit whatever you’re carrying in the 3 litre bucket, you put it into the 5 litre bucket, it just means that over the lifetime of that 5 litre bucket it might carry 3.5 litres of something, 4 litres of something and exactly 5 litres of something.
Based on this metaphor, the temptation is to treat your work like sand you’re trying to fit into a bucket. Do you have just a little bit more than 3 litres of sand? Ah don’t worry, you can just pile up the sand on top of the bucket and you don’t need the 5 litre bucket. This is wrong, and it’s where many teams have trouble with sizing. Suddenly you’re trying to fit work into a bracket it’s too big for. This is tempting – everyone wants to impress with how much you can get through – it’s also how your sprints start to not deliver.
Instead of piling work on, treat the work you’re trying to to like water in your bucket – if you have 3.5 litres of water, you can’t put it in a 3 litre bucket. It has to go in the 5 litre bucket. If anything, you want a little bit of breathing room in that 3 litre bucket to avoid splashes.
Being a little pessimistic, and being strict with your workload, helps to ensure that your points and backlog are sized with the understanding that your work might grow. Working like this can mean that some of the numbers associated with your projects can get big, bit it’s vital to see your projects are sized sensibly and realistically, given the unpredictability of the work you’re doing.
PolyArch Product Management 