Questions for software engineers about estimates.

Marco Rogers

This was 20 years ago. The industry has shifted in and pretty big ways. As a manager for the last 10 years, I've had different experiences growing teams of engineers. Many of them have the impression that their instincts are the only ones that matter. Many people react poorly to being told "uh, no that's not right."

At the same time. Many engineers are starved for experienced mentorship where none is available. There's nobody else to talk to about whether their estimates are any good.

Marco Rogers

I didn't realize at the time that the support I had early in my career was not only good but also atypical. It wasn't until my 3rd job that I had my first experience of managers and more senior dev who were unhelpful and also not better than me at what we were doing. That was wild. And pretty frustrating.

julian

@[email protected] story points make no fracking sense.

They make sense within the context of a team so long as the team is roughly aligned with how much a point is "worth", arbitrarily.

And then of course they loop in contractors and other teams that don't share the same point worthiness and suddenly are surprised when the estimates make no sense.

julian

@[email protected] for what it's worth I'm pretty bad at estimating. It drives @jay-moonah up the wall

Marco Rogers

But back to estimates. My process for estimates is still pretty informal. Some folks here have pointed to books and blog posts that outline much more rigorous methods. But that doesn't appeal to me. I gravitate towards work environments where keeping things informal is expected. And that usually means there is a lot of flexibility in determining the tradeoffs. E.g. timeframes or scope of work.

Marco Rogers

Here are some the heuristics I tend to use.
* If you're giving hard estimates further than 3 months out, you're probably making it up.
* We can and should break large efforts down into phases or milestones. Those should target 3 months or less so the estimates can be meaningful.
* Getting good at swaging these 3 months milestones means you *can* give fuzzy estimates about large efforts. 4-5 milestones means "this could easily take 18 months".

Marco Rogers

* Estimates will vary greatly based on the size and experience of the team.
* Part of the job of a project lead is to break down the work into manageable chunks. This is largely where we *design* the system to be built. Hint: this part is missing in a lot of dev processes.
* Below two weeks or so of work, the ownership should be given directly to the engineer who will do the work. If they say yes, then we're good. As I told someone earlier, I hate "story points" with a fiery passion.

Marco Rogers

I'm fairly confident in my estimates. But what does confidence mean? It does not mean that I hit my estimates all the time. It means that I think my estimates are meaningful and useful for doing planning work. I am also confident in my ability to adjust my estimates as things become more clear. And I'm confident in my ability to communicate these changes clearly to stakeholders so they can decide what they wanna do.

Marco Rogers

Here are some things that I do to make sure I have high confidence in my estimates.
* I talk to my team and learn what they are capable of. As a manager or as a peer engineer. Estimates don't mean anything if the other people involved won't or can't do what is asked.
* I quickly identify which parts we are not experienced in. What things are outside of our current experience and competence. Those parts are labeled high risk.

Marco Rogers

* I front load the high risk parts. Meaning we work to explore those parts early in the project. The sooner we gain clarity, the sooner we can refine the estimates. You can also do short proof of concept sprints to achieve this goal.
* For anything longer than a few weeks, I create documents to outline the important decisions and assumptions I'm making. I loosely refer to these as Project Documents. And in my opinion we don't do enough to teach people how to create these.

Marco Rogers

For any less than a month, we don't need to do a lot of paperwork. Just create a one-pager and then let's just go do the thing.

I should round this out by wrapping it in some context. The statement above implies the kind of environment that I prefer, and thrive in. A fast-paced one where we develop and ship changes in relatively short increments. In recent years, that has meant high growth tech startups. These guidelines won't work as well in other kinds of environments.

Marco Rogers

@floby I don't like talking about "delay". It leaves out the part where we're getting smarter about things as time passes.

✿ Floby 💉😷💨

@polotek not necessarily, when looking specifically at lead time for example, the expectation is that you can bring it closer to 0. To me that translates about a team getting smarter about their code authoring and testing practices, their necessary vs unnecessary dependencies and the maintainability of their code base.
But as I said, I'm more trying to find which tool is going to get the number of ongoing initiative per developer below 1.

Marco Rogers

@floby uh, all of these things are about getting smarter over time. What am I missing?

✿ Floby 💉😷💨

@polotek yes, they are, but I was pointing out how I don't think that talking about delays prevents accounting for the team getting smarter.

Marco Rogers

@floby I don't think it prevents it. I do think it makes it harder. I see it as mixed signals. I just think saying things are delayed (because we got it wrong) feels different from saying we are updating the estimate (because we got clarity on the following things).

Ciggy Bringer of Smoke

@polotek

How much of this is some kind of unsaid but held belief that 'I'm only as good as my own ideas' and then fighting for them? I wonder this all the time when it comes to vocations and professions where that seems to matter more.

Just asking from the Helpdesk Jockey position where nobody tells us we're per se wrong all the time, but nobody is also telling us we were right but the break/fix being resolved, lol.

Marco Rogers

@ciggysmokebringer yeah this is how I interpret it when employees ask for more clarity on their roles and responsibilities. Or to understand how they are being evaluated. They wanna know how to tell if they are doing a good job. The answer is fuzzier thank people want it to be. But it's still possible to give employees more confidence in that answer.

Marco Rogers

@ciggysmokebringer for help desk roles, I would tell people to get more curious about what metrics are used to evaluate their department. Is it tickets closed per month or per quarter? Is it CSAT score? Is it mean time to resolution (MTTR)? You should understand those metrics, and then ask your manager to help you track it back to your own work. How did your closed tickets contribute to your departments overall numbers. Does that make sense?