So I was thinking about #noestimates. I'd think we could agree that IF estimates were not needed, we would not use them, because waste. (If not I have something interesting to learn.) And WHEN they're not needed, we'd not use them, I should think?
/1
Now I want to suggest that estimates are /always/ waste. They are not product (I hope) so they are automatically waste. We should want to get rid of them on those grounds.
/2
Now I am somewhat bemused by people actually arguing FOR estimates, rather than saying "well, they are waste, but unfortunately they are often necessary, so we should be good at them". Maybe someone will explain that to me. But that's not my point.
/3
Since they are waste, if they are not necessary, surely we all would like to get rid of them, save only the people whose job it is to produce estimates. Their hands are not clean and we'll ignore them.

Now I want to tell you a story.
/4
On C3, we estimated all stories in days. (After a while, I think we went to points. If we did, I'm sorry now.) And we kept track of how many days / points we got done in an iteration, and next time we planned, we'd add up the points on the desired stories.
/5
We'd sign up for /about/ that many. Sometimes less, if we felt the stories were actually harder than when we estimated, or if someone with special knowledge was away, or if there were all hands meetings, or whatever.
/6
We (usually) had a pretty healthy situation, and so it (usually) went pretty well. If we were a little optimistic, the Yesterday's Weather would adjust it, and if we could identify why we fell short, we'd improve something. It was all pretty good.
/7
Estimation was working pretty well for us, most of the time. The estimates usually didn't go out of the room: we just used them for our own selection of work. It seemed like the thing to do, because we had been taught to do it.
/8
We also had acceptance tests for every story. Every single one.

Had we known the trick, we could have broken our stories down into single acceptance tests, and streamed them in. That would have reduced the variability in story size very substantially.
/9
Variability was already quite low, because we never undertook anything with a very large estimate: we'd split it or spike it. But had we gone to single acceptance test, the variability would have been even smaller, and we could have always just signed up for, say, 10 stories.
/10
We could have eliminated those estimates entirely. Now the purists will say "but you were still estimating" and yeah sit the fuck down. The point is we could remove this active estimation with some mechanical process that looks like counting, not estimating.
/11
It would have reduced waste, reduced time spent estimating, reduced time spent doing arithmetic, reduced time thinking about variability that wasn't needed. Had we thought of it, it would have been a good thing to have done.
/12
Since estimates are always overhead, always waste, every such elimination, if it can be done readily, at lower cost than the original estimation, it SHOULD be done, because we should always reduce waste.
/13
What is the limit of this activity? We should keep eliminating waste, including waste from estimates until there is none. The limit is:

NO ESTIMATES.

That's why it's a good idea and why it's probably a good hashtag as well.
/end

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Ron Jeffries

Ron Jeffries Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @RonJeffries

Feb 1
I signed up so as to reply, saying:

This is the most outrageous public intentional example of Dark Scrum that I have ever seen.

The very notion of "insubordination" is counter to Scrum principles and Agile principles.
The notion that the ScrumMaster (thanks above for term ScrumBastard) can give any orders is directly opposed to the notion of ScrumMaster as a servant leader.

The idea that management gets to say whether people stand up or sit down is ludicrous.
Jira is a terrible tool for team communication. Either Slack or email are far better. If the SM wants Jira updated, they should do it themselves. 

This is horrible and ridiculous all at the same time.
Read 4 tweets
Jun 24, 2021
I'm wondering some things about developers on Scrum teams. If you are one, please try these surveys, and pass the thread on to other Scrum devs.

How many developers on your team?
Do you have a trained ScrumMaster and/or Product Owner?
How long are your Sprints?
Read 7 tweets
May 9, 2021
I have what seems to me to be an "interesting" problem in my long-running Dungeon series. A dungeon is an array of tiles. Randomly placed in the array are rectangular rooms.

1/8
Rooms are connected from room N to room N-1 by halls from center to center, either first H then V or first V then H. This means that a given all way can cut through any other room, two halls can be side by side, making a wide hallway, and so on.

2/8
Like this:

Complex map in top right of dungeon picture.

3/8
Read 10 tweets
Mar 18, 2021
What matters?

Could we maybe stop fomenting hatred?
Could we maybe start calling it out as wring?

1/2
What doesn't matter?

Dungeon 124
I want to get a creature to lead us to the WayDown. And I feel the need to improve the campground. Also St. Gertude. And, as often happens, we don't go where I expect. Neat outcome, though
ronjeffries.com/articles/020-d…

2/2
Yes, I see a typo. Will fix. If you see two different ones, let me know.

3/2
Read 4 tweets
Feb 21, 2020
while i wait for a call from "the nurse", here are some thoughts about tests, including but not limited to TDD.

XP describes to kinds of tests, Programmer Tests, and Customer Tests. These names describe who the tests primarily serve.
Now in XP there are really only two main roles, programmer and customer. i don't want to argue about this right now, but customer is who the product is being written for, or their representative, and programmers are all the devs, testers, whatever software makers you have.
XP doesn't really contemplate separate testing. Like Scrum, at the end of the iteration, the "programmers" deliver a working tested integrated version of the product. N.B. tested.
Read 12 tweets
Jan 22, 2020
The thing about a framework, Scrum, TDD, whatever, is that it is a massive simplification of how the thing "should" be done.

A good framework has rumble strips and guard rails. When you hit those, they alert you to issues that the beginner would likely miss on their own.

1/9
As such, the framework IS NOT TRUE. If you follow it blindly, you will probably be OK, but you'll not be doing as well as you could, nor as well as the framework provider has in mind.

2/9
You're supposed to look up when the rumble strip rumbles, and think about how you got off the road. You're supposed to survive hitting the guard rail, to think about maybe slowing down for curves.

3/9
Read 9 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!

:(