These two comments nail it for me (summarising below replies).
Estimates can be lowered on request, but it wont change how long the work takes. Retrospective should address this behaviour.
Estimates can be lowered through the trading of feature richness, this trading can start when story estimates are initially floated and the rationale explained. Prefer this over former.
--- In firstname.lastname@example.org, Ron Jeffries <ronjeffries@...> wrote:
> Hello, langvtran. On Thursday, January 20, 2011, at 8:01:58 AM,
> you wrote:
> > What is the correct role for the PO to play here?
> > I'd like to disagree on the view that PO's should not influence the
> > estimates of the team. I believe the PO does and should influence the
> > estimates of the team. The goal is to ensure that minimal marketable
> > feature are being delivered first. She can do this by listening to her
> > team and then fine tuning the acceptance criteria. Another example is
> > when an estimate seems "off", she should ask why. It could be the team
> > was thinking of building something more complex than she needs. Or there
> > could a very valid reason that she didn't realize before.
> > This should be in a team context and not command-and-control. The PO
> > does not get final say on estimates but should be allowed her input. If
> > the PO can convince the team to decrease their estimate, so be it. If
> > the team cannot complete the story that sprint because it was bigger
> > than expected, it would be a good topic for the retrospective.
> In the scenario you describe, I would not say that the PO is
> influencing estimates. She is using estimates to change what she
> asks for, to make what she asks for smaller.
> She's not saying "do that faster or cheaper". She's saying "oh,
> that's expensive, how about if we did this instead?"
> See what I mean?
> Ron Jeffries
> Speed is ppoor subsittute fo accurancy. -- Fortune Cookie