15 ms·

Some anecdata: I also used to believe estimates were nigh useless. This quarter we made a serious effort to estimate the work involved in each task, across a te

Some anecdata: I also used to believe estimates were nigh useless. This quarter we made a serious effort to estimate the work involved in each task, across a team of 5 people–so a total of roughly 50 person-weeks of work, broken up into tasks of 1-6 weeks. And this was for a project that involved building a new product, using a lot of technologies we hadn't used before. Almost every estimate was on point. There was one task estimated at 3 weeks that took two days, and one two week task that took 5. Other than that, every estimate was within a week. Now, I definitely think that we got lucky in some significant ways, and I wouldn't bet on being able to achieve the same level of accuracy next quarter. But I'm a lot more optimistic about the possibility of estimates than I used to be.

alfonsodev 10y ago
The problem is that as you said it takes a 'serious effort', and yet you think you were "lucky"(perhaps experienced, intuitive, mature, knowledgable enough), but other teams that aren't so "lucky" make the same effort without the results and get frustrated, because is frustrating to be late all the time. So I can understand that some people just want to drop estimations, but I don't agree. I wrote a comment below on why still we need estimations and how I think the risk and frustration could be reduced.
makmanalp 10y ago
I kind of agree with this - recently I had a good manager who forced us to do proper estimates. He had a knack for noticing things like "hey, this task you put together is way too big to be one task" or "this task is super vague". And often he was right: if your tasks are all like "implement X feature", you're going to be way off. I realized that I just fundamentally misunderstood how I should be doing estimation. Previously, the way I did it was "well it sort of feels like a day, I guess". Now, what we did was: a) Before estimating, have some certainty about what exactly we want the feature / behavior to be. This is usually the top mistake teams make, and it's a problem. This can come from talking to users, designers, whoever. Focus groups, user testing, design sprints, whatever you want. This all happens before the estimation starts. If you're figuring out what a feature should be doing while estimating time, or even worse, while implementing the feature, you've failed already, and all bets are off in terms of estimates, but also just in terms of finishing things in a reasonable amount of time and in terms of actually building a feature that an end user wants, as opposed to building what's convenient to the developer at the time. It also helps the developer because it's not actually fun to be figuring out requirements in the middle of writing code. b) Now that you have certainty, you go do research. Have you done a thing similar to this before? Pull up the ticket. How long did it take? Whose time did it take? What were the pitfalls, if any? Then go look at some code and start thinking about implementation: what would this take? What modules / files would you have to change? Does this have architectural implications? Should you be talking to anyone else? When you start doing this, you force yourself to think about the actual, real work to be done, and away from the realm of hazy bullshitting. You find all sorts of weird issues you didn't see before, which helps your estimates be much more accurate. Put these in the ticket, to ask your teammates about later. You find things about the task itself that are vague. Note these in the ticket also, and remember to ask about them later. You also can immediately tell if you need someone else to do something before you can get started, so make a separate ticket for that and assign to the appropriate person. Also, resist the temptation to write code just yet. Finally, now, you can make an estimate. Some people prefer t-shirt sizes, others prefer hours. It doesn't matter, just pick one, have it standard across the team, and go with it. c) Now that you have a clear set of features and a reasonably clear roadmap, you and your team sit down together at a table. You discuss work that needs to be done. You bring up issues to each other about tickets. If any of them get solved (often does), then great. If not, it gets moved to the next sprint, along with anything that depends on that. If it's urgent, you make a new, separate "research" task with the purpose of figuring out the remaining details, and leave some room at the end of the sprint to possibly be able to pull in that new task, once it's well-defined. You never pull in a task for a sprint by making up a bullshit estimate for it, regardless of top-down pressure. Every time we violated this rule, it ended up biting us in the ass. Finally, now with actual estimates, you as a team make decisions on what takes high-low priority. Then you figure out blockers: what needs to be done first so other team members can work on things, and you focus on those first. Then there is stuff like Anyway, if you start doing this seriously, in a few sprints you'll be hitting estimates like clockwork. It's actually a very satisfying feeling to have clearly defined tasks and execute as a team. And for reference, a) was done by our manager / designer before the sprint planning. b) and c) used to take us around half a day (3-4ish hours) total to plan a 2 week sprint. All in all, very worth it. edit: Final rule here is that the people who are doing the work decide on the estimates themselves. Never management. Other engineers get to weigh in, but only to make the estimate larger, not smaller. This takes off a lot of pressure from engineers in terms of delivering. At first, the focus is to plan a sprint and just deliver on what you planned. If that means taking on less work, and you finish early, then fine. You can always take on more work once you're done. Once you can always deliver what you promised, only then do you start adding more work. This way, everyone is realistic about the work that can be done, and overpromising is less of an issue. If there is something urgent, the manager gets to say "hey look, this is what we're committing to this week, these are what we'd have to not do to do the thing you want. This is a level of transparency that usually makes stakeholders happy, and at that point they're free to make the decision, as opposed to being angry later.
seanwilson 10y ago
> Almost every estimate was on point. There was one task estimated at 3 weeks that took two days, and one two week task that took 5. Other than that, every estimate was within a week. Exactly, and in other cases you'd have a 5 day estimated task that took 2 weeks but given enough estimates the high and low ones should roughly balance out. If estimates are always widely inaccurate there's a big problem somewhere.
- pdimitar 10y ago
  Yes there is a big problem. Managers reducing all estimates in the hopes of looking professional and thus getting a raise from a higher-level manager, making the programmers' lives a living nightmare in the process. It's the same problem 99% of the time.
  - deleted 10y ago
    [deleted]

alfonsodev 10y ago

The problem is that as you said it takes a 'serious effort', and yet you think you were "lucky"(perhaps experienced, intuitive, mature, knowledgable enough), but other teams that aren't so "lucky" make the same effort without the results and get frustrated, because is frustrating to be late all the time. So I can understand that some people just want to drop estimations, but I don't agree. I wrote a comment below on why still we need estimations and how I think the risk and frustration could be reduced.

makmanalp 10y ago

I kind of agree with this - recently I had a good manager who forced us to do proper estimates. He had a knack for noticing things like "hey, this task you put together is way too big to be one task" or "this task is super vague". And often he was right: if your tasks are all like "implement X feature", you're going to be way off. I realized that I just fundamentally misunderstood how I should be doing estimation. Previously, the way I did it was "well it sort of feels like a day, I guess". Now, what we did was: a) Before estimating, have some certainty about what exactly we want the feature / behavior to be. This is usually the top mistake teams make, and it's a problem. This can come from talking to users, designers, whoever. Focus groups, user testing, design sprints, whatever you want. This all happens before the estimation starts. If you're figuring out what a feature should be doing while estimating time, or even worse, while implementing the feature, you've failed already, and all bets are off in terms of estimates, but also just in terms of finishing things in a reasonable amount of time and in terms of actually building a feature that an end user wants, as opposed to building what's convenient to the developer at the time. It also helps the developer because it's not actually fun to be figuring out requirements in the middle of writing code. b) Now that you have certainty, you go do research. Have you done a thing similar to this before? Pull up the ticket. How long did it take? Whose time did it take? What were the pitfalls, if any? Then go look at some code and start thinking about implementation: what would this take? What modules / files would you have to change? Does this have architectural implications? Should you be talking to anyone else? When you start doing this, you force yourself to think about the actual, real work to be done, and away from the realm of hazy bullshitting. You find all sorts of weird issues you didn't see before, which helps your estimates be much more accurate. Put these in the ticket, to ask your teammates about later. You find things about the task itself that are vague. Note these in the ticket also, and remember to ask about them later. You also can immediately tell if you need someone else to do something before you can get started, so make a separate ticket for that and assign to the appropriate person. Also, resist the temptation to write code just yet. Finally, now, you can make an estimate. Some people prefer t-shirt sizes, others prefer hours. It doesn't matter, just pick one, have it standard across the team, and go with it. c) Now that you have a clear set of features and a reasonably clear roadmap, you and your team sit down together at a table. You discuss work that needs to be done. You bring up issues to each other about tickets. If any of them get solved (often does), then great. If not, it gets moved to the next sprint, along with anything that depends on that. If it's urgent, you make a new, separate "research" task with the purpose of figuring out the remaining details, and leave some room at the end of the sprint to possibly be able to pull in that new task, once it's well-defined. You never pull in a task for a sprint by making up a bullshit estimate for it, regardless of top-down pressure. Every time we violated this rule, it ended up biting us in the ass. Finally, now with actual estimates, you as a team make decisions on what takes high-low priority. Then you figure out blockers: what needs to be done first so other team members can work on things, and you focus on those first. Then there is stuff like Anyway, if you start doing this seriously, in a few sprints you'll be hitting estimates like clockwork. It's actually a very satisfying feeling to have clearly defined tasks and execute as a team. And for reference, a) was done by our manager / designer before the sprint planning. b) and c) used to take us around half a day (3-4ish hours) total to plan a 2 week sprint. All in all, very worth it. edit: Final rule here is that the people who are doing the work decide on the estimates themselves. Never management. Other engineers get to weigh in, but only to make the estimate larger, not smaller. This takes off a lot of pressure from engineers in terms of delivering. At first, the focus is to plan a sprint and just deliver on what you planned. If that means taking on less work, and you finish early, then fine. You can always take on more work once you're done. Once you can always deliver what you promised, only then do you start adding more work. This way, everyone is realistic about the work that can be done, and overpromising is less of an issue. If there is something urgent, the manager gets to say "hey look, this is what we're committing to this week, these are what we'd have to not do to do the thing you want. This is a level of transparency that usually makes stakeholders happy, and at that point they're free to make the decision, as opposed to being angry later.

seanwilson 10y ago

> Almost every estimate was on point. There was one task estimated at 3 weeks that took two days, and one two week task that took 5. Other than that, every estimate was within a week. Exactly, and in other cases you'd have a 5 day estimated task that took 2 weeks but given enough estimates the high and low ones should roughly balance out. If estimates are always widely inaccurate there's a big problem somewhere.

pdimitar 10y ago
Yes there is a big problem. Managers reducing all estimates in the hopes of looking professional and thus getting a raise from a higher-level manager, making the programmers' lives a living nightmare in the process. It's the same problem 99% of the time.
- deleted 10y ago
  [deleted]