A team member start listing fairly aggressive deadlines (for the project everybody is working on) -- something that is to be done well can take 4 to 5 days, and he lists it as 2 to 3 days.

The program manager and the CEO are both happy, because that means people will work overtime and salary is lower as a result, and faster goal reached, etc. People do get burned out and it is not so long term sustainable.

Are there good ways to handle it? I can talk to the management but sure it is a conflict of interest, because they want people working overtime and people don't want to always work overtime. (unless you tell them sprint for 2 months and we will give you 2 weeks extra holiday). If enough coworkers say this is not good, we can tell the management, but some coworkers don't care about quality as much (if shorter time just sacrifice quality), and some coworkers also like to please the management, and the remaining may not want to make noise to suggest that they don't want to work hard.

4 Answers
4

If you get assigned to a task with an estimate you did not yourself, and you feel the estimate is not accurate, send the following email:

Your boss is named Harry, and the guy that estimated the task is called Snoopy.

Subject: Regarding task #XXX
estimations

Dear Harry,

I've been assigned to work on the task #XXX. I noticed that the
estimations was made by Snoopy.

I feel unconfortable with that estimation and I can't commit I will
be able to do it in that amount of
time.

I suggest that Snoopy do the task instead as he seems to be
able to do it in less time than me.

I have a suggestion to avoid such situations. Why not using Planning
Poker to do estimates? Planning Poker
is a consensus-based technique for
estimating.

It is a technique that minimizes anchoring by asking each team member
to play their estimate card such that
it cannot be seen by the other
players.

The meeting proceeds as follows:

Planning Poker is a serious issue, not
a game. But when you introduce
Planning Poker Cards at your next
release planning meeting, team
interest level (and participation)
will shoot straight up and, even
better, you'll walk away with what is
most likely the most accurate project
time estimate you've ever had. Here's
how it works...

The most experienced developer (or the Scrum Master) for each feature
provides an overview of the
functionality for that feature. Team
members can ask questions and
participate in discussions until the
feature has been fully discussed. No
one is allowed to mention time
estimates during the discussion. The
Product Owner makes a note of the
final consensus.

Each team member selects a Planning Poker Card representing their estimate
of the amount of time (usually Story
Points or Ideal Days) required to
produce that feature and lays it on
the table face down. Again, time
estimates are not permitted to be
mentioned out loud.

Everyone turns their cards over at the same time.

Team members with high and low estimates are given the opportunity to
make their case for supporting the
amount of time they have estimated.

The process is repeated until the team reaches a consensus. Preference
may be given to the estimate of the
developer who will be responsible for
implementing the feature in question,
but the Product Owner, acting as
moderator, should help in the
negotiation.

A timer is used to ensure that each discussion phase does not drag on. The
moderator or Project Manager controls
the timer. Once the allotted
discussion time has passed, another
round of Planning Poker ensues.

The entire process forces each team
member to fully think out their
position and to be able to present
their justifications to the team. No
one has more authority than anyone
else, and the project time line is
developed without pressure or bias.

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law. However, props to you all the same. This might be the most accurate way yet of predicting project time, assuming of course that even stray estimates aren't discarded as erroneous data.
–
NeilNov 3 '10 at 11:31

That's why "velocity" (or real factor), must be applied to the estimation you do. Human just can't estimate tasks with accurary if longer than few minutes
–
user2567Nov 3 '10 at 11:46

Yeah, I wonder why not spend a good focused 8 hours to do the job, but instead spend 1 hour to estimate the time is 8 hours, and spend 7 focused hours today and 1 hour tomorrow to do the job?
–
Michael WNov 3 '10 at 13:03

+1, but I would remove the long suggestion for Planning Poker and condense it into one line offering a chat about it. Bosses have this neat visual filter installed into their brain where any line of text past the sixth or seventh automatically transforms into lorem-ipsum text. :)
–
nlawalkerAug 4 '11 at 20:46

You WILL burn out, and they will lose productivity in the long run because of it, either by your lack of motivation, or filling your position by some other new hire.

They are potentially sacrificing project quality by sacrificing 'quality' time.

They are being reckless with their valuable employees.

At the end of the day, they aren't the ones doing the work. They are going home to their wife and children while you neglect yours working overtime.

Not to mention, they are the ones getting paid the most. They are taking advantage of you unfairly. Find a better organization, one that knows about team dynamics, preferably one that is employee owned.

This in a nutshell, especially #1. A sane company doesn't think "If we force everyone to work overtime, we pay them less!" - that sounds like something I would hear Mr. Burns say on The Simpsons.
–
Wayne MAug 4 '11 at 20:10

@Wayne M Perfect analogy, I have worked for that type before... not a good place to be!
–
StylerAug 4 '11 at 20:27

2

If discussions with your manager fail, this will be your last option. In some cases, this is the only way to illustrate that forcing unrealistic deadlines, while "highly productive" in the short term, are detrimental in the long run.
–
Joel CAug 4 '11 at 20:40

Ouch. It really depends on what type of person your program manager is, though if he's reasonable, try to rationalize with him. Sit him down and explain that while results are exceptional now, at this rate the chance of bugs are tripled. Even if it isn't evident now, if in 6 months time a major bug gets discovered which costs three times as much effort to resolve, in the end it was a net loss, not a net gain.

Just be careful how you say it. You don't want it to come across as some sort of a threat. If your program manager is a PHB (pointy-haired boss), I'd try to convey the same message in a meeting with him and his boss (and if you can convince some of your coworkers to join in, do so since it affects them too, right?). Be prepared to offer an alternative estimate, such as 4 days, which is not 5 days, but it's not 2 either.

I can totally understand where you're coming from. It's not in your best interest nor in the best interests of the company in the long term.