Estimation Padding and Velocity in Scrum

Velocity is primarily a tool for helping the team plan what they can achieve in a sprint and for identifying blockers. Real value needs to be measured by results and it is the PO's job to maximise the value of the work done by ensuring the team are always working on the business's priorities. The PO can use sprint reviews and other communication channels to show evidence that value is being delivered through product improvements.

It's true that motivation and productivity can be a problem for any workforce, regardless of the delivery frameworks used. Scrum arguably can help motivate teams because it encourages customer engagement, collaboration and getting regular feedback on the results. Team motivation and commitment is ultimately a function of the culture, working conditions, rewards and may other factors.

Mohit -

Padding and/or taking on less work than could be reasonably completed at a sustainable pace happens when team members have been punished in the past for missing (unrealistic) deadlines.

Trust and respect are two key tenets of successful delivery approaches. Senior leaders need to trust that team members will be trying their best and will have a legitimate sense of urgency about completing their work so team members then will be encouraged to do their best.

Remember that a sprint forecast is just that - a forecast. There could be any number of reasons why less work is completed than was planned. Information radiators such as a burn-down chart provide an opportunity for the team to self-assess their progress and for stakeholders to feel comfortable that progress IS being made. If the burn-down chart stays relatively flat till late in a sprint, the team should be challenging themselves to discover ways of delivering in more of a flow rather than a batch manner.

Kiron

Keep in mind that the team shouldn't stop working just because they've finished all the work planned for the sprint. You should have a healthy, prioritized, product backlog. What's the next item on the list? Can it be finished before the end of the sprint?

Keep track of your actual velocity over two or three sprints and then, during a retrospective, discuss with the team whether to increase their planned velocity. Help them make the decision, whether, or not, to change how much work they can commit to completing in a sprint.

Thanks Kiron. Yes, I understand trust & respect should be there.

What I wanted to know is how well it usually works in real world.
Have you experienced padding or under commitment by development teams? And having known that, how did you address that to improve the situation without making the development team accountable for it?

There is a big mistake on the statement itself. Padding does not exists in estimations. If you people think that is valid then they are DOA (dead on arrive). So, forget to talk about estimation if you consider padding as an option.

Thanks Kiron. Yes, I understand trust & respect should be there.

What I wanted to know is how well it usually works in real world.
Have you experienced padding or under commitment by development teams? And having known that, how did you address that to improve the situation without making the development team accountable for it?