3 ms·

I once had a manager who insisted on time estimates, but used them in a way that I actually found valuable. You'd write out all the tasks involved in a project

I once had a manager who insisted on time estimates, but used them in a way that I actually found valuable. You'd write out all the tasks involved in a project add them all up, and then say "this will take T" Then he'd say, "okay, what would it take to do what you just said in T/2?" Then you'd cut stuff until you got to T/2. The project then, very often, would take me the original T. This seemed to work a lot better than just doubling the initial estimate to 2T.

techsin101 7y ago
In UI design you do this exercise where you put everything in 4 categories. Must have, should have, could have and won't have. Take your idea and jam it into these for while being 100% honest. It does the similar thing as you mentioned. But truly like the idea
- mettamage 7y ago
  MoSCoW, I learned this studying CS
hinkley 7y ago
A lot of devs have trouble decomposing work into small enough chunks. This guy had a way to force that, at least a little.
robert_tweed 7y ago
I'm stealing this with the caveat that it could put pressure on a developer to work out requirements, which isn't always what you want. If used correctly, to remove "gold plating" from an MVP, this seems like a great technique. Another estimation trick that I've found to be very effective over the years is to start with the same sort of task breakdown and finger-in-the-air estimates. Next, start to make a mental list of all the things that could possibly go wrong with each of those tasks. Add those to the list. Most developers with some experience don't add these initially because they don't consider them to be "tasks", but can come up with a huge list surprisingly easily when prompted. Now factor in all the extra time for dealing with those unexpected-but-will-definitely-happen issues. The original estimate is your best-case, since almost all developers tend to estimate optimistically. The new one is the worst-case. A good rule of thumb is that the worst-case is 16x the best case, so if you got less than that, it's a good indication you didn't think of enough things that can go wrong. If it does follow the typical curve, 4x the best-case estimate will be a good expected-case (75% chance of success). What this manager did right was prioritising the tasks, because estimates are just the starting point. The next thing is to know what absolutely must be done for MVP and what is nice-to-have. If you have 3 weeks to launch an MVP then that MVP needs to be achievable in about 4 days. Otherwise you are setting unrealistic expectations. If you actually finish it in 4 days (unlikely) then well done. You can start adding polish in order of priority, starting with a load test in production to find out as many "unknown unknowns" as possible.
afarrell 7y ago
If you look at that conversation, you'll see that the value comes not from the number T but from the list of tasks which can then be cut.

techsin101 7y ago

In UI design you do this exercise where you put everything in 4 categories. Must have, should have, could have and won't have. Take your idea and jam it into these for while being 100% honest. It does the similar thing as you mentioned. But truly like the idea

mettamage 7y ago
MoSCoW, I learned this studying CS

hinkley 7y ago

A lot of devs have trouble decomposing work into small enough chunks. This guy had a way to force that, at least a little.

robert_tweed 7y ago

I'm stealing this with the caveat that it could put pressure on a developer to work out requirements, which isn't always what you want. If used correctly, to remove "gold plating" from an MVP, this seems like a great technique. Another estimation trick that I've found to be very effective over the years is to start with the same sort of task breakdown and finger-in-the-air estimates. Next, start to make a mental list of all the things that could possibly go wrong with each of those tasks. Add those to the list. Most developers with some experience don't add these initially because they don't consider them to be "tasks", but can come up with a huge list surprisingly easily when prompted. Now factor in all the extra time for dealing with those unexpected-but-will-definitely-happen issues. The original estimate is your best-case, since almost all developers tend to estimate optimistically. The new one is the worst-case. A good rule of thumb is that the worst-case is 16x the best case, so if you got less than that, it's a good indication you didn't think of enough things that can go wrong. If it does follow the typical curve, 4x the best-case estimate will be a good expected-case (75% chance of success). What this manager did right was prioritising the tasks, because estimates are just the starting point. The next thing is to know what absolutely must be done for MVP and what is nice-to-have. If you have 3 weeks to launch an MVP then that MVP needs to be achievable in about 4 days. Otherwise you are setting unrealistic expectations. If you actually finish it in 4 days (unlikely) then well done. You can start adding polish in order of priority, starting with a load test in production to find out as many "unknown unknowns" as possible.

afarrell 7y ago

If you look at that conversation, you'll see that the value comes not from the number T but from the list of tasks which can then be cut.