Questions for software engineers about estimates.

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?