Storypoints for dummies
Imagine a king who has established a unit of measurement based on the size of his foot. The king cannot prevent other kings from using their own feet to set the measurement standards in their kingdoms. The Chinese apparently had their own unit of measure; it was nearly ten percent larger than the American version, and the standardized unit in Hong Kong was even larger! Could anyone have imagined such a thing? Traders traveling between kingdoms might all discuss the same items, but they all have different understandings of what the size of a foot really is.
It was the early homo sapiens who started measuring things. Their units of measure were pretty basic: the distance between home and a girlfriend’s cave might have been measured in the number of days it took to walk there; long periods might have been measured in moon cycles; weights measured by what a man could carry; and so on. It workedósort of. These methods were not very precise, but they served ones purpose. It has taken a long time for mankind to determine how to express distance and time in standardized ways equally understandable to everyone.
Why not just estimate in hours?
Imagine a pair of software developers. If you were to ask developer one how much time it would take him to develop a given feature, he would estimate based on his experience and knowledge. Let’s say he estimates the job will take him eight hours. Developer 2, doing the same thing, replies that the same job will only take him five hours. Now imagine that they are both correct in their estimates. What just happened? Well, just like the homo sapiens who expressed distances in days of walking, somewhat an inaccurate method. We need to separate a few variables to achieve better precision.
The developers estimated the size and complexity of the proposed feature as well as the human effort required to deliver it. However, the calculations didn’t stop there; they also predicted the speed at which they would be able to work. Both developers mistakenly assumed they would be able to maintain full control over how fast they would be able to work on the project. Unless they each have a functioning glass orb somewhere, making predictions like this should be made with caution. The speed at which one can work is highly dependent on many variables such as the environment one works in, the maturity of one’s team, and the quality of the description of the feature to be developed.
So, what if we could estimate the size of a task without trying to make predictions that require a magic orb? If we remove speed from the equation, we get a higher degree of precision. Story points allow us to do just that by expressing the size of the work item and nothing else. How do they do this? The general idea behind story points is that they determine the size of the work item independent of the person who will do the actual work. One of the challenges with story points is that there is no exact definition of how big a task needs to be to fit into a single story point. No one device can measure the size of a given task; so, just like the early homo sapiens, we need to come to a common understanding of what a single story point represents. The king in our little story used his foot as a reference; this worked fine so long as he didnít try to use the measurement outside his own kingdom.
Setting the standard
It’s common practice for all members of a group to use a small task as a reference to compare the value of story points. The group members choose the task that can be estimated with the highest confidence and assign to it a story point value that they can all agree on. The task’s story point value is less important than the level of confidence one may have in the value. Once this value has been set, the size of each subsequent task may be compared to the reference task, making it more or less possible to estimate the weight or size of any given task. In general, a group of people use powers of two, or have a scale such as 1, 2, 5, 8, 20, and so on when estimating. The larger a taskís estimation, the less certain and accurate it is. Using the Fibonacci sequence helps teams recognize this uncertainty, deliberately creating a lack of precision. It usually makes sense to split these larger tasks into multiple smaller ones, so the estimate for each individual task becomes more reliable. However, the more we split tasks, the more the total estimate will tend towards infinity due to rounding errors and fear factors that we multiply into fine-grained estimates. In order to get a higher degree of confidence in the accuracy of the story point value, techniques like planning poker or scrum poker can be used, wherein members of a group are prevented from influencing each other.
Ok, but what about the budget?
The reality is that story points are pretty useless on their own when it comes to budgeting. If you can come up with a way to measure how long it takes to deliver a single story point completely, you should be able to find out much more about your projects, such as the total cost of the project or its expected delivery date. A single story point, over the time it takes to deliver this story point, is what we call velocity. Velocity is a value that can only be discovered by measuring the time it takes a team to deliver the requested output. To determine your teamís velocity, you must define a very limited set of featuresóestimated in story pointsóand measure the time it takes to deliver this set. After tracking the velocity for a while, you will notice that the value eventually settles at a stable minimum and maximum numbers. Now, what you need to understand is that this technique works best for monitoring a project. Other techniques exist for when you need to estimate the total cost of a project at its conception, but that’s a story I’ll need to explain later.
Long story short
What you need to remember from this post is that story points are an approximation of size, effort, and complexity for a batch of work, and that the value is independent of the entity who will eventually do the work. The size, effort, and complexity that is represented by a single story point, is valid only to the group of people who did the estimation in the first place. The story point values of one team cannot be compared to those of another team. You need to know that velocity is the speed at which a single story point can be delivered. Velocity needs to be calculated on a regular basis in order to supply your team with reliable minimum and maximum values. The advantage of representing the size of a work item in story points through the evaluation with a group of people is that you receive a high degree of confidence in the accuracy of the assigned value.
You can learn more about the planning poker technique here and here.
I hope you enjoyed this post.
If you have a remark or a question, I encourage you to leave a comment.
