Roman Estimation: A Simple, Easy and Quick Alternative to Story Points
Don't Fix Your Story Points or Velocity, Just Stop Using Them
There are two kinds of teams:
Teams that do use Story Points and Velocity.
Teams that don’t use Story Points and Velocity.
Pretty simple, right?
When I encounter teams that fit in bucket 1, they rarely use Story Points and Velocity effectively. That’s why I prefer encountering teams that belong to bucket 2. It’s easier to bring clarity than to remove confusion and then bring clarity.
In bucket one teams, I frequently observe lots of time wasted on planning poker sessions, re-estimation, or false claims that story points are equal to complexity. Plus, they’re at risk of being bullied by others outside the team based on their Velocity. To top it off, it’s pretty likely they still work on items that are way too big.
When talking to teams that fit in bucket 1, the name of the game frequently becomes unlearning and relearning, which is difficult and time-consuming.
When I join teams that fit in bucket 2, it’s still pretty likely that they work on items that are too big, but at least they’re not wasting time to uphold a Story Point and Velocity bureaucracy that doesn’t add value.
To solve all these problems, I came up with a new estimation approach called Roman Estimation, which has the following benefits compared to Story Points:
It is easier to understand (it takes 5 minutes to get it)
Shifts the discussion away from having an accurate estimate towards right-sizing, thus preventing waste and wasteful discussions.
Protects the team from people outside the team who push them towards the ‘Your velocity must increase’ rabbit hole.
It prevents silly re-estimation discussions.
It’s not as scary as #NoEstimates or right-sizing (and you can get started immediately without any simulations). You’re still making estimates, so nobody has to be scared.
So, what’s Roman Estimation? Let’s dig in!
Roman Estimation in a Nutshell
I recently watched Gladiator II, and like many others, I was incredibly disappointed. During the movie, I was bored and distracted. I started thinking about Story Points and Velocity (yes, that was how boring the film was!).
The movie reminded me that the Ancient Roman crowds passed judgment with Pollice Verso whenever a gladiator had been defeated, meaning with a turned thumb. A thumbs-up* meant the defeated gladiator lives. Thumbs down meant they would die.
*Historians dispute the accuracy of the modern depiction of the thumbs up and thumbs down. A thumbs-up meant the gladiator would die, and a closed fist would mean the gladiator should live.
With Roman Estimation, we ask the following simple question:
“If we were to starting working on this on a Monday morning, would we reasonably expect to complete it by Friday end of day?”
The team members answer with a thumbs up or a thumbs down. If everyone gives a thumbs up, excellent, then we believe the work to be right-sized, small enough to be picked up and finished quickly.
We’re not asking how much time we think it takes precisely or how complex we believe it is.
We ask ourselves: is this small enough to be completed within a week? If yes, great! And if not, let’s talk about how to make it smaller.
If someone votes thumbs-down, we talk about it, and then we discuss what we could do to make it smaller. There are two options:
If we all agree we can’t make it smaller, we leave it as is.
If we can split it up and make it smaller, we do that and estimate again to check whether we’ve right-sized the issue.
Roman estimation is fast and easy to understand, and it shifts discussions away from trying to produce accurate estimates to slicing work into small pieces (right-sizing).
If you think 5 days is too long, you can even agree on a shorter interval together as a team. The same logic applies, regardless of the interval you agree on.
How Do You Enter Your Roman Estimates?
You can reuse your existing estimation field and enter ‘1’ if it’s right-sized and enter ‘2’ if it’s too big, but you don’t know how to make it smaller.
That’s it! You’re all set.
And another bonus: you’re still producing Story Point and Velocity estimates, yet you’re not calling them that way.
If the fact that your velocity is lower causes issues, multiply 1 by a factor that will produce a velocity that’s similar to what you had before. However, it’s much preferred to discuss and be transparent with your stakeholders rather than to obfuscate through factor multiplication.
Give Roman Estimation a Shot!
Roman Estimation inhabits a nice little sweet spot: You have the soothing comfort of producing an estimate that your stakeholders or team may crave, yet it completely shifts the conversation away from the estimate's accuracy and toward right-sizing.
In short, the next time you’re faced with a team that sucks at using Story Points, let them try out Roman Estimation. If you’re working with a team that wants to start estimating, get them started with something easier than Story Points. See whether it works, and don’t take my word for it!
The beauty of right-sizing with Roman Estimation is twofold:
You’re shifting towards right-sizing.
But you’re still producing an estimate.
We all know that estimates will be wrong, but the point of our estimates is not to be accurate but to have the right conversations and reach a common understanding. We want to produce them with as little waste as possible because let there be no doubt about it that’s what they are: waste.
Let’s say your team is doing right-sizing with Roman Estimation and things are going smoothly. You could even consider to stop using Roman Estimation and switch to right-sizing without entering any estimates at all.
Congratulations!
Now you’re doing #NoEstimates or Right-Sizing, and I should point you to Nicolas Brown's fabulous work on forecasting when you’re doing right-sizing.
I like this as a sort of "baby steps" approach to estimating.
My approach focuses on days-to-complete confidence as well, but in more detail. I've been using this definition for years with teams of all experience levels with great success.
1 = Definitely within a day
2 = Probably a day, maybe two
3 = Definitely within the week
5 = Probably within the week, maybe into the second
8 = Two weeks
>8 = Too big, break it down
I know that's a lot more complicated than a yes or no answer to a 5 day estimate, but it seems to make the whole estimating process digestible for the team. And it results in incredibly accurate estimates and backlog sizing after a few cycles (within 6 to 12 weeks IME). With a stable team that knows their stack well, this model allows me to provide a fairly accurate delivery schedule as much as six months out.
The primary reason I like a more detailed estimation framework is that it acknowledges that "right-sized" doesn't mean everything is roughly the same size. Sometimes one ticket is going to consume the whole iteration. Other times we'll be working on small enhancements and we can stack up five or more. And the two week limit allows the team to go out to the extreme end of what can be confidently estimated. Beyond that, the work is bigger and more surprise-prone than your ability to estimate it.
Love how obvious and easy to understand this is. Can't wait to try it out!