In my current company we're using Scrum with 2 week iterations and a regular planning session.
How planning normally works in our company is that we take a predefined , prioritized (by PO before the planning) product backlog of user stories / PBIs, take PBIs from the top one by one and break it down to tasks to then estimate them in hours (using poker planning and fibonacci) until we reach a given team's capacity.
While this works for most of the teams, there is one 2-person team where I'm a SM, that tends to systematicaly overestimate the tasks by far (as those developers are being paid by an hour in this project, and from the record of working with them in another project I know for a fact they have a far better velocity).
Not being a part of this team as a developer, trying to adhere to Scrum I'm refraining from influencing those estimates by any means, however as we approach the deadlines in the project this situation is becoming more and more troublesome.
My question is – is there a way / good practice in such situations, to keep the team on the edge of their velocity and not influence their estimations, or maybe we're doing sth wrong in the process ?
Best Answer
The sin of overestimation is probably less serious than that of underestimation, because the team is at least meeting its commitments and not contributing to the chaos that can occur when commitments are missed (particularly when others depend on a team's output for their own work, as is often the case).
How do you know they are overestimating / undercommitting? Are they spending hours on end in the Starbucks in the lobby? Or is it just something you "sense" based on your understanding of the scope and complexity of their per-sprint output? If the latter, are the individuals perhaps more thorough in elimination (or better yet, prevention) of technical debt? Do they have better test coverage than other teams? Is their software better designed? Do they refactor when necessary?
I'm not standing in defense of all "slow" teams - I've managed some. What you have to know before acting is why they're slow, and what steps can be reasonably taken to increase velocity, without sacrificing the quality of work produced.