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 ?

  • 2
    What happens when they get done their tasks early? Or are they just being slow and no manager/peer is holding them accountable?
    – Telastyn
    Commented Apr 13, 2014 at 21:49
  • 3
    I suspect the problem is the small team size - a 2 person team doesn't have enough people involved for the normal variation between people's estimates to collapse into a more 'realistic' estimate. And, since the people involved are actually hitting their targets, I suspect that they only feel a little bit bad about being so off, so often. I know I've never felt bad about over-estimating something! Commented Apr 13, 2014 at 22:29
  • @Telastyn I'm affraid that bringing manager's control to the team would steer it more into micro-management which is not too agile I think. Manager is holding the team accountable in terms of commited sprints, the problem is however that the scope to which they commit is terribly small.
    – RRob
    Commented Apr 14, 2014 at 8:17
  • @MichaelKohne thats true - if you can overestimate and get away with it - you will :) I'm wondering however if there is something I'm missing from the process of Scrum that can make people more accountable for their work, as in connection to the fact that in Scrum you should not influence the estimations, the team commits to the sprint and that there should be no micro-management from the PM - it seems like we've reached a bug in Scrum :)
    – RRob
    Commented Apr 14, 2014 at 8:22
  • Did you ask the 2-person team the same question? Commented Apr 14, 2014 at 9:14

6 Answers 6


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.

  • I would argue if overestimation is less serious than underestimation, as underestimation can be more or less easily spotted (we haven't finished the scope we've commited to for example) and aided with adding time buffers in next planning. In this particular case its a mixture of being paid by an hour + working on their own projects in the meantime, while theres nothing that stops them from overestimating.
    – RRob
    Commented Apr 14, 2014 at 20:34

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.

  • In this case I'm affraid this is a matter of working on other projects in the meantime as both those guys are doing contractor work aside. I would probably close an eye on this and let the team proceed with this velocity if not for the fact we're reaching our deadlines and it gets more and more tense. I'm affraid this situation will give our manager, who's not that into agile, an argument that micro-management and asking developers 10 times a day "how's work? done yet?" yields better results than letting the team self organize and in the long run we might drop the scrum.
    – RRob
    Commented Apr 14, 2014 at 20:51

@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.


  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.

  • #1 - So they're doing the work they like AND are not productive, but they don't want to switch? They need to make a choice or get replaced. #2 What? #3 - Do you have the authority to talk to these people? Then find out what is going on. #4 - Don't let them "game" the system. It's not about how many story points can you do. I can do more story points if I decrease the amount of work for each story/cut the same task into more stories, points, etc. Think of the project in broader terms. Some type of review needs to be done and they need feedback on not getting enough done.
    – JeffO
    Commented Apr 14, 2014 at 13:09
  • @User/JeffO - thank you for the insight! #3 - I do communicate a lot with the team, however beyond stating clear the deadlines and trying to remove all the obstacles and the risks for the team, there's little that comes to my mind I can do, thats why I wanted to get opinions from the noble community of stachexchange :) #4 - at this stage we're doing hours estimation for tasks. This is because when we were starting the Scrum, I've noticed people had a big problem estimating low level tasks in virtual story points, and maybe that is an issue, but Im not sure.
    – RRob
    Commented Apr 14, 2014 at 21:22
  • #4 My experience with hour estimation is that you need it in the beginning. After you have completed some sprints you know how long (not time) and hard a task was and whether you over-/underestimated. = After a while you estimate from your experience like: "This task is comparable to the task of one week ago. It will probably have the same story points."
    – User
    Commented Apr 15, 2014 at 8:10

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.

  • The problem here is that we're having more or less the same velocity, it just feels that there's more "fat" than "meat" in the team's work :) The stimulation might be a very good idea, and I think I'll try to aproach it soon but I dont think this will work on those guys as having some spare time and additional paid hours is a stimulation per se
    – RRob
    Commented Apr 14, 2014 at 21:27
  • My point is precisely that an agile team shouldn't "have more or less the same velocity", they should improve and get more productive over time. Maybe they aren't aware of that. Maybe they think it's just fine to always hit the same score and do whatever they want with the rest of their time. Hopefully, just restating things and reminding them of the upcoming release will ring a bell. Also remember that you're not alone here, the PO might be a reliable ally (see my edit) Commented Apr 15, 2014 at 8:50
  • Bring up the point that the team's velocity hasn't improved over X sprints and ask "how could we do better ?": They could improve the velocity by just overestimating tasks: more points per sprint equals better velocity. How to prevent them from doing this?
    – Giorgio
    Commented Apr 15, 2014 at 9:00
  • "overestimating tasks" - you mean user stories right ? Tasks don't have points, stories do. Story points are usually on a coarse grained scale. Since velocity improvement is based on the previous sprint, you can't keep blatantly overestimating them sprint after sprint otherwise you'll end up with enormous values. Commented Apr 15, 2014 at 9:09
  • @guillaume31: Yes, I meant stories, sorry. Also real velocity will not increase forever but will asymptotically reach a maximum. So eventually you cannot blame developers for not increasing the velocity over X sprints since they might simply have reached their best velocity already. In other words, looking at the velocity alone is not sufficient to find out if the developers are overestimating stories.
    – Giorgio
    Commented Apr 15, 2014 at 9:17

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 ;).


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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