Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am asking this from a purely hypothetical standpoint.

According to the Sprint Planning Meeting section in the Scrum Guide: "The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint."

Questions:

  1. What is there to stop the development team from over-estimating intentionally the time it takes to complete user stories?
  2. If there is a long-term contact with the product owner and development team, should this be defined in the contract as some sort of violation or breach of contract?
  3. Who would be responsible for discovering such a violation?
  4. How could the product owner prove that such a violation was taking place?

Thank you for reading.

share|improve this question
5  
Developers can be afraid that their velocity will be used against them. In my experience they have relaxed more when the velocity is kept private. Obviously, when someone is not pulling their weight, they need to be managed or let go, but teams will be productive when they do not have to worry about lots of the BS. When scrum was introduced at my company, it was billed as something that made Boeng 5x productive. Some devs were yelled at for having low velocity while everyone is watching wuthout regard for how experienced they are and how difficult their bugs were. That causes overestimations. –  Job Aug 4 '12 at 15:59
6  
The development team has to keep their reputation as miracle workers. Anytime you start putting legalistic and punitive restrictions on developers you'll kill productivity and team morale far more than any minor over-estimates will. –  jfrankcarr Aug 4 '12 at 22:50

4 Answers 4

up vote 6 down vote accepted

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.

share|improve this answer
    
Thank you for your reply. The concept of Velocity answers my question. –  David Kaczynski Aug 4 '12 at 17:45
4  
"then you have people that consciously go against agile development, and those people should be handled appropriately" - hanged, drawn and quartered? Those bastards! They don't agree with the Holy Way! How could they let to be born on the surface of this Earth? Down with them at once! –  Aadaam Aug 4 '12 at 21:33
2  
Aadaam: "handled appropriately" might simply mean to put them on a different team, or let go. And not because they refuse to accept the agile way per se, but because they aren't working together with their team. No matter what development methodology is chosen, if some members of the team refuse to work together, that situation needs to be addressed. –  Bryan Oakley Aug 5 '12 at 3:41
    
@bryan: and if all devs do it their way then it's the scrum master who isn't working together as a team. Now who should be let go? –  Kevin Aug 5 '12 at 18:19
    
@Kevin: obviously I can't give a hard and fast answer since this is a hypothetical question. If you have a dysfunctional team, it needs to be dealt with appropriately. If the team isn't working well together, adjustments to the team need to be made. Maybe that means getting rid of some team members (devs, qa, po, scrum master), or maybe it means they need better training. –  Bryan Oakley Aug 5 '12 at 18:25

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.

share|improve this answer
    
So...first hire rock stars ("true professionals") and then sit back and smoke a cigar? –  Kevin Aug 5 '12 at 18:21
    
@Kevin: true professionals aren't "rock stars". But to be honest, yeah, if you have a team that works extremely well together, often your best strategy is to get out of the way and let them work. They will constantly deliver work that they are proud of, and you don't have to worry about them intentionally over-estimating the amount of work to be done. –  Bryan Oakley Aug 5 '12 at 18:31
    
My point was that hiring that team is not so easy. –  Kevin Aug 5 '12 at 19:05
    
@Kevin: Why do you think that? Almost every team I've worked on over the past 20 years has been this way. Most programmers (in my experience) are highly professional and wouldn't think of overestimating -- it simply serves no purpose. Maybe I've been lucky. –  Bryan Oakley Aug 5 '12 at 20:21

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.

share|improve this answer
    
Great answer. I provided padded estimates to a recent project (double what I thought realistic). Every sprint, every milestone, right on time. And devs were working full speed--there was just more to it than I had originally considered. –  Kevin Aug 5 '12 at 18:27

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?

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.