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 once wrote a lot of posts on what had worked for me with estimation, and why things useful in one context didn't seem to help me in other places.
An insight that's stuck with me: In a high trust environment, almost anything can work - and in a low trust environment, almost nothing will.
@polotek I’ve used three methods. First one is simple - plus 50% of the time between now and the current delivery guess. 2yr projects take 3yrs etc. Update as new estimates are produced. It’s been reasonably accurate, useful when someone else is giving you estimates that you depend on. Second when you control the work is to prototype and iterate in smallest possible steps. Third is to use Monte Carlo to combine estimates. Like this tool https://www.getguesstimate.com/
@polotek When I worked at Fitbit, the company had Ken Rubin teach a 2-day agile training once a quarter to new hires. This gave everyone a shared, foundational understanding of how to break problems down into known knowns and unknowns, how to estimate effort or timebox until able to estimate effort.
Many of us were skeptical at first, but we did actually get much better at estimating at the team level. Success was how accurate the team was in delivering the work committed to in a 2 week sprint.
@polotek The techniques I learned from Ken Rubin’s agile training worked well on other teams I managed at Spotify & Stripe. With about 2 months of data and collaboration, teams could start breaking down multi-quarter projects to estimate with reasonable accuracy.
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.
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.
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".
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.
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.
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.
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.
The only possible measure of success is shipping the feature before it gets cancelled.
I have had conversations about estimation in waterfall, capital-S Scrum, agile, agile-shaped-object, and incident war room settings. Really the primary value of estimating is forcing someone to sit down and imagine all the parts, where they live, what they’re made of, how to package or deploy them, how to test them, who is going to make them, and what is likely to go wrong along the way.
Anyway, my rule is, take a SWAG, add 20%, double then move up to the next unit of time. For example: SWAG is 4 days, add one day, and double for 10 days. Final estimate: 10 weeks.
@polotek A secondary benefit is making a map of the things the team is going to have to learn in order to complete the thing.
A tertiary benefit is that you can come up with a sense of how long it might take. The perception is that managers will take that estimate and expect you to finish it in that amount of time.
You might think your manager foolish for expecting this, but this perception is just so the team doesn’t take its foot off the gas.
@janl@polotek when I’m working with teams that have little experience in estimation I ask them to work very strictly on one-week sprints due to point #4 you make. If a team can’t estimate what they can get done in a week, there’s no way they can estimate months at a time. By enforcing a short interval they have the chance to start learning how to estimate with smaller item sizes first— after which they can start increasing their skill.
@polotek 1. You can only estimate with confidence in a team that has estimated before and learned from the actual-estimate difference. Usually you need to do this a couple of times before your estimates hit.
Estimation confidence is a funnel, wide at the beginning of the project, highest confidence is just before the end of the project.the funnel starts with a 100% confidence interval at least.
@polotek I was once consulting for a project that did estimation on a two year scale and I just couldn’t believe what I was seeing. I later asked the PM how they did this and he referred me to (no surprise here) Steve McConnell’s Software Estimation book. While a bit heavy on precision and process, the first few chapters teach the most important bits:
@janl@polotek digression: hard to overestimate McConnell’s impact on software engineering process in the 90’s and 00’s, and even today. Rapid Development and Code Complete were the bibles back then, and still form a significant part of the vocabulary of people who came of age in that era
Add comment