A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Estimation: Keeping track of whether people tend to over- or under-promise ..

At the start of every cycle, one of the most critical tasks that a team takes on is about getting a list of features ready for the cycle. So, for this purpose, the Product Manager has a list of features in a specific order of importance (how these features are prioritized is a different post altogether) and the idea is that the team is expected to be able to figure out how many of these features can be done in the current cycle. This is typically the task of the project manager / leads or the Engineering Manager. The person concerned looks at the features, assigns them to various senior people to look at and review and then figure out an estimate. In most cases, an estimate can be prepared through various methods (they can be very scientific such as Function Points or they can be based on previous estimates of similar features), and some kind of interaction with the Product Manager and the designer is required. This interaction is meant to flesh out the features to a more level of detail so that the estimation becomes easier and is likely to be more accurate. However, once the senior engineer / team member gives their estimates, it is now upto the project /engineering manager to make the next move.
And this is where the experience level of the manager comes into play. It is not simply as easy as taking the estimates and starting to convert these into a list of doable features along with a schedule. One of the biggest subjective factor comes into play. I have had long discussions with managers across different teams, and the approach they follow is reasonably similar. When they have worked with their senior folks for some time, they have a good idea about which person is likely to give an aggressive estimate, and which person is likely to give an estimate with buffer that exceeds the comfort level of the manager. If they were to let the estimates go ahead as it is, it would not really work since when the feature execution would start to happen, things would go awry in the schedule. There would be a lot of fire-fighting in the case of the person whose estimates were aggressive, and if the features were critical, all sorts of things could go wrong, and in trying to get the work done, quality problems might start popping up. At the same time, you certainly don’t want to go with a lot of buffer, since that would mean that features that could get done were not going to happen.
So, typically what managers do is to make changes to the estimates passed on by their senior team members. For aggressive estimates, the manager would typically add more effort so that the estimates seems more realistic, and vice-versa for the estimate where a lot of buffer might be added. At the same time, it is the role of the manager to ensure that their team members know about their estimates biases, and the manager would need to spend a lot of time in ensuring that they can get the estimation capabilities of their team members correct. Eventually, it is all traced back to the responsibility of the manager, and he/she would not be doing their duty as a manager unless they made an effort to correct matters.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>