Ron Jeffries Profile picture
Jul 24, 2018 15 tweets 3 min read Read on X
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

Aug 15, 2018
Most companies today have "Managers". The companies are organized around an imposed hierarchy of responsibility and (somewhat) associated authority. We might prefer some other structure: we might reflect on other existing structures within those companies. /1
But that's the way most companies are: a hierarchy of power, authority, responsibility. The management functions of planning, organizing, staffing, directing, and controlling (Drucker) all pretty much follow that hierarchy. /2
Manifesto Agile is mostly agnostic to the hierarchy, instead describing how people might best work together. About all it says about organization is "business people" and "developers", and that's pretty vague. /3
Read 12 tweets
Jul 25, 2018
Apparently we need a little digression on waste. I'll leave it to you to study the 8 kinds of waste that lean addresses, and the Toyota notions of muda, muri, and mura. Maybe some links, below, if I remember.

I think about it a bit more intuitively than that.
/1
Presumably we're "in the business" of building something. Building a software product is at the top of my mind, but we could be writing a book or having a bake sale. The "something" is the software, the book, or the cookies.
/2
Everything we do to produce that produce is an "expense". It goes on the expense side of the ledger, if I understand how ledgers work, which is open to question. The money we get from our cookies goes on the revenue side.
/3
Read 15 tweets
Feb 8, 2018
Today I'm thinking about precision. In a sense I might be against it. Stick with me. The eminent @ivarjacobson is promoting Essence, which is a candidate approach to precisely defining methods and practices (and more) for software development. /1
My initial reaction to this was that it's a great idea, and frankly I still think it is. The ability to say more clearly what a method is and is not has many potential advantages. Clarity is of course one. Increased ease in creating a team's own method is another. /2
A team /always/ has its own method, and organizations that try to impose their "standard" method on all teams are making a serious mistake. This happens all too often. /3
Read 19 tweets
Feb 6, 2018
I’ll put this poorly. will try to do better later, in another medium. the thing is this. faux-agile, would-be-agile, downrightfuckingfake agile are going to be all over. people are even trying to /standardize/ agile, to nail it down, to define it. /1
people are “certifying” rank agile beginners, three-day agile leaders, one-week agile whatevers.

people are pushing their scheme, framework, angle, over all the other angles.

some of the things being pushed are downright wrong, incorrect, mistaken, maybe even evil.

/2
Still, many of the ideas in there are pretty good ideas. that is, they’re half-decent words describing something that can only be experienced to be understood.

more important, to me:

@KentBeck has said he created XP to make the world safe for developers.

/3
Read 12 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!

:(