I just joined a new team as scrum master and I have observed team has forecast 35 effort points in every sprint and they are delivering more than 50 points . I feel there is some problem with estimates. I need to make sure that estimates should be not very high . Is there any way to control this ?

  • Hi Shailesh, what's the specific question? – Tiago Cardoso Aug 6 '19 at 8:26
  • Edited my question . – shailesh Aug 6 '19 at 8:47
  • 2
    I could see both the team and the PO being happy with it. So what is the actual problem that needs solving? I know it's not by the book, but "this is not how you should do it" is not going to make people change. If you can present a real life problem that is solved by more accurate estimations, that would go a long way towards having them improve.. – nvoigt Aug 6 '19 at 10:19
  • 1
    Why is delivering more points a problem? If the team is consistently meeting its Sprint Goals, what's the issue that you're really trying to solve for here? Scrum is generally most effective when measuring goals and results, rather than trying to track against estimate deltas. – Todd A. Jacobs Aug 6 '19 at 20:45
  • 1
    Just to be clear, is it that the team has a consistent velocity (amount delivered) of around 50 but they only pull 35 into planning? This kind of buffering could be healthy (or not) depending on what is driving the behavior. If this is the case, I'm happy to write up a more thorough answer. – Daniel Aug 7 '19 at 21:38

What you need to do is document the facts.

Keep a clear record of the forecasts for each sprint and the actual deliveries.

Make sure you have dates for each fact.

Once you have a few weeks worth of data then you can approach the scrum master and ask them to explain their methods of estimation and suggest ways to improve it.

You cannot expect to change anything by making claims of what you seem to observe as a newcomer unless you have it clearly documented.

You may also want to find out if you can get to some historical data; possibly the past few weeks have been special circumstances that you aren't aware of, and usually, they are better at estimating.

You can also shadow them by running a parallel (hidden) system with your estimates and show them - after a few weeks - how you approach is better.

| improve this answer | |
  • I checked the last 7 to 8 sprints and it seems that this problem is since before that . Even out going scrum master agrees about this problem and tried to solve this but no luck . – shailesh Aug 6 '19 at 9:26
  • great! Then shadow them with your estimates, and show them - after a few weeks -how your system is more accurate. (Added this to the answer) – Danny Schoemann Aug 6 '19 at 9:40

Is this regular? As in more than 5 sprints in a row? If yes, then you should help the team improve their estimation. And this is to ensure that they are fully capable of estimating properly.

If they are still estimating higher than expected, that's a good thing. This means you have enough buffer to deal with unplanned problems like additional work, change in scope etc. Just make sure, it is because they underestimate their own skill level and not because they are incapable of correct estimation. Because the latter will cause problems some day.

| improve this answer | |
  • I want to upvote this, because it is mostly on target. However, in Scrum the goal is quick, “close enough” estimation in the aggregate, not “correct” or guaranteed-accurate planning values. Too much emphasis on accurate predictions instead of responding to change is the enemy of agility. – Todd A. Jacobs Aug 23 '19 at 4:42
  • I agree with the "close enough" estimation part. That's why I said, it is not really a problem if estimate mismatch. Although we should still thrive to get developers to come as close to actuals as possible. Situations where they estimated 2 days for 2 hours work is not a good sign either. – jitendragarg Aug 26 '19 at 5:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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