The key point of Velocity and user story estimation is to serve as relative measurement of what can developers finish during sprint. Velocity should not be used to compare to other teams. So, if the developers will over-estimate the user stories, the velocity will go up and they will be forced to either do more work next sprint or over-estimate again.

This is what agile developers should be aware of. If you have developers that consciously go against this system, then you have people that consciously go against agile development, and those people should be handled appropriately.

Also, the product owner IS part of the development team. He is not someone from outside. He is part of the team and should be present during all important team meetings.

What is there to stop the development team from over-estimating
intentionally the time it takes to complete user stories?

I would say pride, and a sense of professionalism. Hire true professionals and you don’t have to worry about it. If you have people that are intentionally trying to subvert your development efforts you’ve got bigger problems than just estimation issues.

The history of software estimation is a history of underestimation, not of overestimation. In my experience, even when developers think they are padding their estimates they usually are still being overly optimistic. Projects having estimates less than half of reality are not uncommon.

Underestimation is also significatly more risk than overestimation, because of what happens to the project down the road. Underestimated projects will likely take longer than the same project overestimated because of the exponential increase in “catch up activities” such as bug fixes because of cut corners, constant status meetings, replanning and rescoping. Slipping milestones also have downstream effects, affecting the timelines of other teams and customers. They absoultely destroy the confidence of partners in the team’s ability to deliver.

In essence, anytime a team is worried about overestimation I would stress that the much larger risk is underestimation. For a great review of this and other estimatation related topics, I love the book Software Estimation: Demystifying the Black Art.

An essential principle of agile development is total openness. So in theory, at least, there’s nothing to stop the scrum team from robbing you blind, other than the fact that it would be immediately obvious. That, and the fact that the team will have started by promising this openness, and that people are basically honest.

So (I’m asking this purely hypothetically): What’s to stop you from stealing from the local sweet shop?

Somewhat less flippantly: the team’s estimates will be checked against reality at the end of the sprint. They stand at the board every day to say what they expect work on, and the following day they answer for their progress against that commitment. What more could you want?