Fibonacci isn’t the only option anymore
Scrum Pointing Sessions are kind of odd when you stop and think about it. Why do we put so much info into a single number? Why is that number on a Fibonacci scale? Why does the internet want developers to debate this number so hard? We’re playing poker?? Well, turns out there’s another way, one that removes all the guesswork.
Pointing sessions are where you assign the level of difficulty to tickets. A Fibonacci scale (1,2,3,5,8…) is usually used so that larger tickets have more of a gap between them. Now, you may be wondering how levels are chosen, and that’s a good question with no real answer. Some people pick a “baseline” ticket as a 1, and then scale all other tasks agains it. Others average factors like risk, time, and complexity together. The idea is that the number is a bit vague so devs will fight, sorry, “_debate_” it and new info will come to light.
Sometimes, instead of debating the actual feature, people argue the literal number. If you called a feature complex, the devs would agree, but one thinks it’s a 5 and the other thinks it’s closer to 8, so now you have to talk about it for another 10 minutes. But what do the numbers even mean? The problem is in the units: they intentionally lack concrete values. That single number can encompass a lot of data.
I recently talked with another team and was blown away by their pointing system, based off this style. In their version, only 2 things matter: do you know what we want *and *do you know how to do it:
1 — you know exactly what you wantand you know exactly how to do it. These are things like running scripts, updating the db, making simple front end changes, adding basic properties to the API.
2 — you know exactly what you want, but you aren’t sure how to do it. Most features would fall into this category. You’ll get a feature request so you know what you want it to do, but you aren’t sure how to get it to work
4 — you aren’t sure what you want or how to do it. This is the vaguest so it is what gets assigned to most bugs and spikes.
That’s the whole point. _One of the greatest paradigms in programming is the “Single Responsibility Principle.” The idea that when processes are at their best, they’re doing one thing. Trying to wrap things like complexity, risk, time, and more into one number leads to a lot of debate. And to me, it rarely feels like time well spent. Because it’s just an estimation anyway, so it’s not even _that important. It feels like Agile has become focused on the number because it’s a *ritual. *For instance, there’s pointing poker and people can “win” if they get the right number. That definitely feels like pulled focus.
In the ticket! If there’s a high risk task, put that in the ticket! Overly complex? Write a warning, and link to any examples that led you to believe that. Instead of arguing over numbers, spend that time by adding helpful notes and resources to the ticket. By putting things like that into words, it frees up the number to focus on conveying specific information. New dev? Stick to 1s. Looking for new features? Look through the 2s. Want to bug hunt? 4s for d4ys.
If you have found your pointing sessions are getting inefficient, I really would encourage you to try SimplePoint (it doesn’t technically have a name, I just like that name). But honestly, if you have a tight team and Fibonacci is working just fine, don’t feel like you have to rush to change things. Only look for a solution if there’s actually a problem.
happy coding everyone,
Do you feel uncomfortable, maybe unprepared, or lost in the darkness to what you can expect from the interviewer? This full scrum interview guide is for you.
Full workshop breakdown on how to identify non-functional requirements (NFR) as a part of an agile project inception, including preparation and execution tips.
In this article, I will discuss how I adapted Avi’s original canvas to the needs of the teams I was coaching, elaborate on the different elements of a working agreement, and share with you a step-by-step guide to facilitating collaborative working agreement development workshops.
We'll walk you through how to develop situational awareness on large and complex projects as a new Agile Coach or Scrum Master
Although we still talk about programming as a standalone career, the dominance of technology in our lives makes it clear that coding is much more than a career path. In my opinion, computer science is more than a college major or a high-paid job; it’s a skill, essential for thriving in a modern-day economy. Whether you work in healthcare, marketing, business, or other fields, you will see more coding and have to deal with a growing number of technologies throughout your entire life.