Questions for software engineers about estimates.

Marco Rogers

@spoltier for what it's worth, I hate "story points" with a fiery passion.

Marco Rogers

I'm glad I asked this question explicitly in this way. Lots of great info in the replies. Thank you all for being thoughtful and candid.

I have some thoughts, but they'll have to wait until later. I will share some of my own experience though. I forget to do that sometimes.

✿ Floby 💉😷💨

@polotek 1. Yes I've received formal training at university to apply heuristics to estimate software complexity and therefore delivery estimates. I've had training and practice afterwards with projection for established teams.

2. Having had training, I know these are educated guesses at best. So yes I start by making things up, until I get more educated (aka gathering knowledge on the requirements and constraints). Within scrum I usually estimate first stories at 8.

✿ Floby 💉😷💨

@polotek (and yes I've been told many times by "scrum masters" and the likes the 8 was an unreasonably high unitless number)

3. I'd say that I'm usually confident 30% to 80% in my estimates. I'd usually measure success by the amount of money we were losing because I'd be selling the time of a team for a fixed scope and price most of the time.

Marijke Luttekes

@polotek I worked with an architect, and we only estimated blocks of 2 hours, 4 hours, 8 hours, and then days. I don't think they did half days over 1.

I also recommend remembering overhead on issues: things like discussions, emails, ticket creation, context switching, communication delays, etc. Overhead starts at 30 minutes.

✿ Floby 💉😷💨

@polotek These days I try to focus on having conversations about delay rather than effort because the main difficulty in my org right now is that priority is shifting constantly (not always for good business reasons) and we're already doing many things in parallel. None of our projects is very complex, but the bulk of what makes it hard to estimate when things will be done is that people get reassigned constantly to other tasks, which results in effort & delay being uncorrelated for a given task

Marco Rogers

Okay. I can give some if my answers to the question about estimates. I've never been presented with formal methodologies around estimation. In my early career, it always seemed like more senior people would just come to with numbers based on fuzzy intuition and experience. This never really bothered me. It's just the way things were done.

Marco Rogers

The reason it was mostly okay is that my early career was as a contractor. I worked for firms that hired me out hourly. Estimates were just estimates. If it took longer, we would explain why and renegotiate the hours. There were conflicts sometimes. We missed something huge on our side, the client was in a bind and couldn't afford to move dates, etc. But none of that fell on me directly as a team member.

Marco Rogers

When I became a Senior Engineer, it's because they wanted me to lead projects. But I became the person who had to answer the question "how long do you think this will take?"

At this point, I had observed a lot of what more senior people talked about and thought about when they did estimates. I paid attention when they asked me questions about my part of the work. So I started to model those things I had seen.

Marco Rogers

One of the key things here is that I still had string mentorship and guidance. There were always people around who were more experienced then me. I talked to them directly and explained my thinking. And they would either say "yeah that seems reasonable" or they would say "uh, no that doesn't seem right. Let's talk about it some more."

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.