Scrum task over estimation

Question

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 ?

Answer 1

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.

Answer 2

I would question every team that gets ever sprint completed all the time. This really isn't the goal. It's all right to push yourself even if it means missing a few. You can always adjust. If they can accomplish everything on time towards the end of the project, maybe they figured it out.

Developers are going to underestimate because:

1. There are serious consequences for not getting everything done.
2. They want the project to last longer, do less work, etc.
3. They are too caught up in the whole planning thing and think they have to be perfect. Maybe they take the whole thing too seriously or literally.

I'm sure there are more.

Regardless of how a team manages themselves, there is still a business to run, so there will be expectations of how much work you get done. Clients have expectations. People like to get paid eventually. Someone paying the bills needs to look at the project and determine if it is going to get completed in a reasonable amount of time. If not, adjust the requirements or adjust the team.

Someone who knows something about how long things take to get built (It appears you've discovered this.) has to address the team. Probably some leader in the company. This is where Jeff Shurt's answer comes in. Can you identify why they're not attempting more? Is it knowing how to plan, being too worried about not finishing a sprint, being less skilled or just slacking off. As part of scrum, you don't look at one day or one sprint. Look at several and notice the trend.

Maybe the hourly people need to be split up? Being on a team that is getting more completed could help to move them along.

Answer 3

@JeffO There is one more which I want to go into detail about:

Thesis 1

These two programmers estimate right but have incomplete knowledge (So do I).

This is a two-programmers-team and those two programmers

1. are very disconnected from the other teams.
2. base their work on a lot of foreign work which is hard to estimate

Since they are only two people it can be more enforced not to communicate with bigger teams because

1. they have more on their sholders (50%), so they can not just go somewhere and chat
2. they are more of a completer-finisher (Belbin), very task oriented, not too connective if it is not for problem solving they do not see any need to exchange with other teams. They are very effective and efficient on their own.

Solution:

1. They change their working place and work as ambassadors in those teams they should communicate more with.
2. In case both are not fond of that idea and very perfectionistic, dislike such change, maybe it is the wrong tasks you pass to them? Maybe they really suffer from these incomplete hack-something-together tasks they get in their user stories. Maybe user-stories with another quality of code are better?

Theses 2

They do not reflect on the tasks or the set of tasks have not so much in common.

Thesis 3

You have got a communication problem. (People always have). You turning to programmers.stackexchange before you attempted to talk to them, could be an indicator. (I do not know)

Thesis 4

How come they overestimate? Story points are no time units. I mean: they need to increase the story points every time to overestimate. You can make a story-point to time mapping from the previous iteration and take this as a basis for time calculations.

xxx This all is speculation but I had fun writing it.

Answer 4

Whatever the methodology, a product will fail if participants aren't motivated.

As a Scrum Master, you're part of the team, not above. The good news is, that makes at least one motivated team member :)

You must ask "why are we failing ?", not "they".

The best time to do that is during a retrospective. Bring up the point that the team's velocity hasn't improved over X sprints and ask "how could we do better ?". Analyze the impediments you're facing. Suggest things that you, as a Scrum Master, could do to remove some of those, and ask the developers what they think they could do on their end.

If there's no particular obstacle but no particular incentive either, propose challenges such as adding an extra bonus story at each sprint as a stimulation, or try to work on delighting the customer with small unexpected features.

It might seem easier said than done, but don't make it a matter of slacking off, guilt, blame or management pressure. Make it about an agile team inspects, adapts, improves, sets itself challenges and gradually more complex goals and has fun and takes pride in doing it.

Edit : Also remember that you're not alone here. The Product Owner is your best ally to push the team forward.

I recall one hard to please PO who always expected small "icing on the cake" features or UI gimmicks during demos and let the team know quite bluntly if she thought we had underperformed. In the end, we started automatically thinking about what could surprise and please her and adding it to the product during the sprint so that the review would go fine. As a result, perceived product quality increased a lot as did team motivation.

Customer satisfaction is a strong incentive especially if approval happens during a public meeting where you don't want to appear unprofessional.

Answer 5

Scrum master is a part of the team and has the right to ask: why did you estimate it that way?

Unmotivated, yet proficient teams start to slip over time. Looking for and discussing indicators other than an artificial velocity can help surface this issue.

Is their code coverage slipping? Why? Are automated tests failing frequently? Is the build often broken? Is defect load being managed? What is the quality of defect documentation? Are features being continuously delivered within the iteration? Are the team members continuing to set goals and suggest improvements during retrospective?

If they task and hour estimate their stories, it can also be helpful to discuss their effort estimates. Look for spike/research tasks that drag on for days and ask to understand how they determined the necessity and duration of these tasks.

Finally look at the variation on how long it takes to finish similar sized stories. Teams that are managing their story point estimates generally have large variances on how long it takes to complete a story. Was that 8 point story that you thought would take 5-10 days to complete suddenly picked up and finished at the end of the sprint in 3 days? Nothing wrong with asking how they achieved such success and pulled of the last minute win ;).

Answer 6

I am just a beginner practicing Scrum. I would like to share my thoughts on this topic. As I understand, effort estimates is overall team activity using planning poker or fibonacci series or a combination of both. I usually try to converge the efforts by replaying planning poker getting brief explanation for the least and highest effort estimation quotes and finally apply Beta-Distribution(i.e Optimistic + 4*Most-Likey + Pessimistic effots divided by 6). This will keep the effort estimation not influence by one or few individuals.

So, what I suggest is make these 2 guys part of another scrum team which enables knowledge sharing and better effort estimates. The other way is to make PO or an SME also provide effort estimates during sprint planning and converge the efforts discussing the motivations/reasons for individual estimates.