Imagine walking 100km cross country over varied terrain. If I gave you a map and asked you exactly how long it’s going to take you could you tell me?

Most people would find this a very difficult task to achieve. However, if you break that walk down by standing at the start line and looking across the first 500m, which you can see is a flat field of grass, you might estimate how long it will take you to walk that 500m reasonably accurately but you still couldn’t extrapolate from that how long it’ll take to walk the other 99.5km as there are hills, valleys, rivers, woods, and other unseen difficulties that you have no experience of walking in.

At the end of the first 500m you can now see the next 500m clearer and you can see that you need to go down a hill, cross a stream at the bottom, and come back up the hill the other side; you know by looking at it that it’s harder than the first 500m but do you know how long it’ll take you with any amount of accuracy?

With each successive 500m section of the walk you start building experience and can relate what you see on the map to the features on the ground. You become more experienced at looking at the map and being able to estimate the relative difficulty of 500m sections of walk and, after a couple of days, you might be able to estimate how much of the route you might expect to finish in day 3.

At this point, in day 3, do you care what the final 500m of the route looks like, or would you rather focus on the next 500m ahead of you?

In this scenario your scope is fixed, it’s a 100km walk, and so time becomes the variable. You could also switch the importance of scope over time - so how far will you get in a week? If I asked you that question at the start, any distance you suggested would be a guess but as time on the walk progressed you’d get better and better at estimating how far you might get by the end of the week.

Introducing the Story Point

In a nutshell this is what Story Point estimation is: the map is your Backlog, each 500m section is a User Story, and each day is a Sprint. Your determination of difficulty for each 500m section is your Story Point value: you’re not estimating time, but can say whether each section will take more or less effort than previous ones. With each day you can also factor in unknowns - the weather, injuries, etc - which will adjust how hard or easy a 500m section might be; each day you can predict more accurately how many 500m sections you could get through that day.

This is exactly the same as Story Point estimation in software development; the development team will work in conjunction with the Product Owner to focus on the top of the backlog, and not worry overly about features at the bottom. Each User Story can be measured in relative effort to other stories, not in absolute time estimates. Over time the team will become adept at estimating stories for the product and will be able to make a reasonably good prediction of what can be committed to a sprint and be completed.

Everyone will eventually try to equate story points to time but it is important, for consistency, to leave the team estimating in story points and trust that everyone would rather see successful software being used with complete ‘Done’ features in place than not. If nothing else, experience shows that there’s not much that can be done to make a highly performing development team go faster, and so story points allow everyone to focus on what is easy, hard, and - crucially - achievable within any fixed time period.

Past performance can be a predictor of future performance but can never become an absolute scale due to the inherent uncertainties of those future stories, especially when, further down the backlog, the details are still unknown.