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.
I absolutely agree, and unfortunately, when using Story Points, sizing of the load may not happen because Story Point's primary purpose (how it was invented by Ron Jeffries) is to obfuscate the size of the load.
Nobody knows what the hell 8 Story Points is apart that it should be similar in size to something of 8 Story Points that we've completed in the past.
Hi Maarten, I like your artickle and I fully agree.
But isn't that pretty much the same as #NoEstimates?
There we have three possible results of an "estimation": too big, no clue or one. What "one" exactly means is up to the team. In our team it means maximum one week.
We started with that more than two years ago, and I'm still convinced that it was one of the best decisions we have ever made. All the useless discussions were history in no time :-)
But I think I will use the term Roman Estimates in future. It certainly sells much better than #NoEstimates and won't cause any heart attacks at management level :-)
Good timing. I'm actually facilitating a discussion this week on estimating alternatives because I've really come to dislike story points. Isn't this essentially just using throughput instead of sizing? For planning use the number of stories a team completes per sprint, on average, which assumes they are all right-sized and about the same size. And, if using a 1 for stories that are going to be pulled into a sprint, then the velocity = throughput, because each estimate = 1 will end up just being a count of the number of stories.
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!
If you do decide to use it, please share your experiences!
Nice one, as it emphasizes the sizing of the load, which is probably the most important thing here.
Hi Milan,
I absolutely agree, and unfortunately, when using Story Points, sizing of the load may not happen because Story Point's primary purpose (how it was invented by Ron Jeffries) is to obfuscate the size of the load.
Nobody knows what the hell 8 Story Points is apart that it should be similar in size to something of 8 Story Points that we've completed in the past.
And that may still be too big.
Yes, exactly
Hi Maarten, I like your artickle and I fully agree.
But isn't that pretty much the same as #NoEstimates?
There we have three possible results of an "estimation": too big, no clue or one. What "one" exactly means is up to the team. In our team it means maximum one week.
We started with that more than two years ago, and I'm still convinced that it was one of the best decisions we have ever made. All the useless discussions were history in no time :-)
But I think I will use the term Roman Estimates in future. It certainly sells much better than #NoEstimates and won't cause any heart attacks at management level :-)
It's the same yet is isn't. You are still producing estimates. So no heart attacks!
Good timing. I'm actually facilitating a discussion this week on estimating alternatives because I've really come to dislike story points. Isn't this essentially just using throughput instead of sizing? For planning use the number of stories a team completes per sprint, on average, which assumes they are all right-sized and about the same size. And, if using a 1 for stories that are going to be pulled into a sprint, then the velocity = throughput, because each estimate = 1 will end up just being a count of the number of stories.
Yes, it's a sneaky way to use Throughput and Right-Sizing by producing 'Roman Estimates'.
It's not really new, but calling it this way makes it more memorable and less scary. Plus you can drop the Throughput truth bomb later ;).
You can explain teams this in 5 minutes. I know because I did it!
I have seem many software teams cargo culting Scrum, Story Points and velocity. This is a valid alternative!
Great idea !!
Pls, one thing I did not catch from your explanation - what are the next steps for these items?:
"If we all agree we can’t make it smaller, we leave it as is."
You just make the effort to make them smaller in the future?
Hi Martin!
If we CAN'T make it smaller, I meant that we believe it's impossible to make it smaller (unless we decide not to deliver vertical slices of value).
Yeah, it should be rare, but I've heard it many times before in meetings. We don't know how to make the work smaller.