Dear Story Points
It’s time to finally understand each other
There is a lot of confusion in most of the Agile teams all around the world about how we estimate stories/tasks. It takes a few hours of research and a few sprints of experimenting, but the biggest problem for most teams seems to be that everyone estimates differently. And that’s where story points come in. Most of Scrum teams use it, it’s part of our processes to estimate our work, iterate continuously and make the sprints more predictable.
So… What are story points exactly?
For the longest of time, developers, Product Owners, roadmaps, clients and pretty much every member of a software development team tried to answer a simple question:
How much will this feature take?
This seems pretty easy: we clarify the task (what needs to be done), get the people that work on the task in the same room and ask them. Right? Well, pretty much, the only thing left is to find the unit of measurement for all this.
The first choice for measuring an estimation would probably be time for most people. Story points are here to change that. And they are doing it with one simple argument: time is subjective, while story points are objective.
Wait a minute.. are you sure?
Yes, I am pretty sure story points are objective, while time isn’t. And I hope you’ll be agreeing with me in a few minutes.
Measuring time is pretty concrete, we all know what one hour is exactly, and we are all thinking about the same thing. But when someone says 1 story point, every single person in the room may think about something else. And this is perfectly fine in an Agile environment because when estimating a feature we have 2 common variables that make time a subjective matter: complexity (which can’t be directly converted into a certain amount of hours) and the people that give the estimation/the person that will tackle the feature.
The reason we need story points is to give everyone a sense of the overall effort needed to complete the task:
- the amount of work
- the complexity of the work
- risks & uncertainties
All these elements are objective, and they depend on the same variables mentioned above only when transposed into hours (time).
Will story points improve our estimations?
Yes, and not only your estimations. But your backlog refinements, roadmaps and understanding of the stories throughout the whole team.
I’ve seen story points do wonders in two specific scenarios: when multiple people chip in and especially when people give very different estimations. There’s no need to panic when we get very different values from multiple people, because this may be a sign that either the task is not ready to be estimated (some elements may not be clear, there are lots of uncertainties) or some members of the team realised something that the others weren’t thinking about.
This happens a lot and it’s never a bad thing. Based on the experience of each developer and what projects he worked on before, new uncertainties may come up. For example, I’ve seen many cases when we were estimating maps and didn’t consider if the design would include clustering the pins on the map, or when estimating a simple login flow, then realising that Apple requires Login with Apple, and so on.
Having developers give different story point estimations and arguing is always a great sign, noting that the task is becoming clearer for everyone.
Learning from our past mistakes made us better
When I initially started working with story points, I was always considering 1 story point = X hours. And so did my teammates. This was our standard. And it wasn’t working. We weren’t completing the sprints and we rarely were put in the same number of hours as initially estimated.
We needed a few sprints to find a new standard, but after estimating the second forgot password story (for example) we already knew: this became so much easier, for all of us.
Also, for the first sprints, in our team, poker cards planning worked like a charm. Although it takes a little more time, it gives everyone a chance to chip in, an argument the estimation is given and get everyone on the same page.
Ok, I finally understand what story points are. But are they worth the time?
A fair question to ask… getting used to a new system of estimating stories can take a while. The best thing here is that you don’t have to nail it from the first time. Actually, under/overestimating may actually help the team realise mistakes they were making, flows that were adding complexity or even uncertainties they didn’t even think about.
It’s tricky to stop seeing a task and saying:
I’ve seen this before, 3 hours at most.
But we must do it, for the sake of our team. These estimations need to satisfy the developers/designers/etc. that will work on the task, the Product Owner/Manager which will need to convert the estimation into hours and communicate with the client, and the Scrum Master which needs to keep it all glued together, making sure that the PO understood the estimation and that the developers are content with it.
There is one example that stood out for me and I’d love to share it with you. We were working on these 2 projects with mobile apps including integration with some Bluetooth IoT devices. They were both very different, but equally uncertain.
For the first project, we used to estimate only by hours, while for the second (which started a few months later) we learnt our lesson and started using story points. The differences? Well, having so many third party integrations and unknowns, we were never hitting the hour estimations. It was also taking us longer. Frustration grew and tasks were rarely finished before finishing the sprint. In the second project, we knew the standard for the estimated workload but always added because of the uncertainties and complexity. This allowed us to be confident in our estimations, fit into them and deliver as intended 🚀
From our experience, we saw three advantages that make our day to day lives a lot smoother:
- we know what we estimate: we take into consideration every detail of the task, complexity, unknowns, all of it; having to take into consideration uncertainties, complexity and workload forces us to have the overview on the whole task, feature, story
- we can finally give an objective estimation: story points gave us an estimation that could be suitable for every member of the team; we all know that a task may take less time for a more experienced developer, but the complexity is the same, and so are the unknowns, while a time estimation is highly dependant on each situation in particular
- we are finishing our sprints: after a few sprints, it got a lot easier for us to understand how many story points we can fit into our sprints, and we are actually completing our flow at the end of the sprint; the actual estimations were accurate, we wouldn’t need to put in 2–3 more hours because of uncertainty we didn’t consider
This is all about story points and their benefits across our teams — that are not too small, by the way.
Wolfpack Digital is based in Cluj and has over 50 wolves who design, build, and launch digital solutions: from idea and strategy to app launch. What we do, is to create a world where technology helps people and can streamline schedules, simplify work, coordinate activities, offer medical support, boost offline activity, offer careful monitoring and advice, and much more.
Sounds challenging, right?
We developed solutions to digitise offline hobbies such as knitting, and apps to help gamblers fight their addiction, or patients find their right medicare plan. We even built a smart toy to encourage kids to go out and play, and smart gloves to help sports trainees monitor their hard work and improve it on the go!
Yup, imagine working on a product with such an impact!
