Questions for software engineers about estimates.
-
Questions for software engineers about estimates. Feel free to answer any of these in any order.
Have you ever had an explicit conversation about how to estimate projects? How did you learn?
If you feel that you were never taught the skill in any real sense, what do you feel you're doing at work when you're asked for estimates? Are you making it up? Have you developed your own personal guidelines?
On average, how confident are you in your own estimates? How do you measure success?
-
@polotek I think I learned the theory of different models of software development in college (early 90s, so pre-agile) and estimation was probably part of those.
My first job out of college was for an educational/games company (CD-ROM releases!) and they definitely put a lot of effort into generating estimates and deriving deadlines from those. I can’t put a finger on how I learned to do it or how well I did it, but as I got promoted to team lead on a project it was certainly part of what I did. There was an expectation that we would get better at it individually and organizationally, but also an understanding that it was hard.
-
@polotek I think having come from this world of releasing software as a physical product makes my experience with estimating and deadlines abnormal in an era dominated by engineers who have come of age releasing online.
-
@polotek gut feeling from previous tasks, but it's almost always "story points" which aren't supposed to be directly about time, so...
In my first jobs that didn't use some kind of agile, I never had to estimate tasks. -
@jimw yeah this is relevant. We do need to keep in mind that massive shift.
-
@spoltier for what it's worth, I hate "story points" with a fiery passion.
-
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.
-
@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.
-
@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 Luttekesreplied to Marco Rogers on last edited by
@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.
-
@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
-
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.
-
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.
-
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.
-
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."
-
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.
-
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.
-
@[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.
-
@[email protected] for what it's worth I'm pretty bad at estimating. It drives @jay-moonah up the wall
-
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.
