During the meeting, each team member answers three questions:

  1. What have you done since yesterday?
  2. What are you planning to do today?
  3. Any impediments/stumbling blocks? Any impediment/stumbling block identified in this meeting is documented by the Scrum Master and worked towards resolution outside of this meeting. No detailed discussions shall happen in this meeting.

In the last question, it states that "Any impediment/stumbling block identified in this meeting is documented and worked towards resolution outside of this meeting".

From my experience, just about every "impediment" results to slippage. So how would you, the average Scrum Master respond to such slippage? Do you assume that only a day slippage in a two or three week sprint is normal and hope for the best? Do you assume that a three day slippage is reason to assign help? What would 'your' tolerance level for slippage normally be? Do you have a formula you stick to (ie: if the slippage is 20% late you automatically assign someone to help)?

I'd just like to get a better understanding of this third rule.

3 Answers 3


Seems to me you are treating a scrum stand-up meeting rules a bit too much like a formula and in your formula there's two steps: 1) someone says they are blocked; 2) I must do X -- help me find X.

Things aren't that simple. The goal of a stand-up meeting is for the entire team to get together and share where they are, what they've done and where they are going. Your rule #3 is there simply to ensure that the meeting stays short and to the point. Reason for that is because you do stand-up meetings everyday and if you start having discussions every time someone brings up a point, you'll end up with 1 hour+ meetings that will get very expensive, very fast... I've been in those, they are not fun.

So since you are looking for a formula, I'd like to propose a modified, 3-step version of what you had:

  1. someone says they are blocked
  2. after the meeting talk to ONLY people that need to be spoken to. Clearly person that is blocked might want to elaborate on what help he/she needs. Maybe another teammate or two want to be involved as well. There's a very good chance, 75% of your team will be able to go back to their work and continue being productive, which is why the advice is to not have any discussions in the stand-up
  3. Do X -- where X is the conclusion from (2), not what the Internet tells you to do. And yes, it will be different for every situation because people get blocked for all kinds of various things.

Few more words of wisdom which I wanted to share...

  1. As a scrum master, your role (and it is very important one) is to make sure your team functions as smoothly as possible. It doesn't mean you can't have a single wrinkle and everything must be tip-top. There will always be blockages that you can't do anything about. It just means, do your best to ensure your team stays productive. So once you find out that something is blocking a story, let your team members go back to work and focus and you take a look to see if you can unblock them. Sometimes you can, sometimes you can't.
  2. Mis-estimation is not same thing as blocked. If someone started working on a story and then realized that it involves 5 times the amount of work. Yes, that's a cause for concern but in this case, as a scrum master you should encourage process improvement to improve estimation. Unfortunately, there will be very little that you'll be able to do in current sprint. Sometimes stories do not get done as planned. That's life. The key question you should be asking yourself and the team is are you doing anything different/better to ensure that next iteration the team will perform better?
  3. "assign someone to help" -- you mentioned that twice in just few lines of text and based on that, I formed an opinion (maybe not a correct one) of what kind of manager you might be. Do not throw more people, technology, chairs at a problem whenever you are forced with one. ASK YOUR TEAM. The point is not to ask your team in a stand-up, but nothing is stopping you to have a one-off discussion and ask your blocked teammate if another person would help. In some cases, higher headcount could help. In MANY cases, higher headcount causes more headache, lowers quality and your schedule slips even further. In ALL cases, your team will know what they need, not us.
  4. Collect and analyze statistics. That's one of the reasons agile suggests short iterations. When we do same thing many times over and over. It gives us chance to improve ourselves, but only if we take the time to look back and see how we've been doing. Your team is too busy delivering work but you can take some time and write down some information. How many times were you blocked per iteration? Is there a person that seems to be blocked more often than others? How much do you typically slip by? (can you compensate by planning less in next iteration). Show this data to the team and ask them where/how they can improve. As Euphoric suggested, a retrospective meeting at the end of an iteration is a great place to do this.
  5. Scrum master IS NOT a manager or a overlord. Remember, don't try to come up with a solution and throw it back at the team. Work with the team and encourage them to come up with their own solution. Then do your best to help the team implement it.
  • You seem to make a lot of assumptions about a lot of things? But regardless, my point was simply (maybe I wasn't quite clear) that in doing legacy 4, 5 or 6 month projects, a single day slippage is peanuts considering you have a lot of time to catch up. But with 2, 3 or 4 week sprints, the time frame is significantly shorter, so the slippage is major. Thanks for your answer. Aug 12, 2013 at 12:37
  • @The.Agile.Manager.2013: One can't really go through life without making assumptions. I'm just trying to give you some advice you can use but just like with anything else on the internets, take it with a grain of salt. What I was trying to get at is that any solution needs to come from the team itself because that's how you get motivation/buy in from your team members to see that solution through. Do you build slack into your iterations? Following Point #4 above, you should have the numbers that indicate how many average unexpected things...
    – DXM
    Aug 12, 2013 at 19:17
  • ...you typically encounter. Start with larger slack to compensate for variability and then through retrospectives work with your team to reduce that variability (assuming larger problems aren't identified which are more important than reducing slack). And the goal not be zero slack, but some manageable number above 0.
    – DXM
    Aug 12, 2013 at 19:19

So how would you, the average Scrum Master respond to such slippage?

There is two parts to this: impediments and slippage.

Slippage can happen due to impediments, but it can also happen due to unexpected problems (which do not need to be impediments) or someone getting sick or something as simple as an urgent field issue. When we're going to miss our goals (or even when we will probably not meet our goals), I will communicate that to product owners and other team leads. Slippage will happen, but where it hurts development is when expectations aren't set properly and estimates/process aren't adjusted to account for the things that cause you to slip. But I would not change anything mid-sprint, certainly not reassigning people to help. Deal with estimate/process improvement in your retrospective & sprint planning.

Impediments on the other hand are times when developers run into a roadblock... a missing tool, some prerequisite code isn't there, some person is out/missing/being unhelpful. They've tried to solve the problem, but cannot. That is your cue as scrum master to immediately track down the cause and unblock them. There should be no "tolerance" for impediments.


You should act on those impediments, but only as far as providing advice and guidance. You should ask them if they require help, maybe negotiate with different developer if they can provide help. But do not provide help without developer's consent. They would get idea that they are micromanaging them too much.

But it is given that those slippages will affect burndown of the whole sprint. So if you happen to know that there will be few day slippage, you should discuss updating sprint backlog with product owner. It will probably result in some low-priority tasks being dropped.

Also, during sprint retrospective, you should bring up this slippage and work out reason for it and what to do not to repeat it again. Maybe the code is mess and requires refactoring. Or maybe the requirements weren't clear enough and you should be more careful next time. Or the library the developer used was poorly understood so you should provide more training. Etc..

  • Thanks for your answer! But I thought you couldn't remove tasks from a sprint? As for the sprint retrospect, it's a good idea! Aug 11, 2013 at 6:05
  • @The.Agile.Manager.2013 If it turns out that a task cannot be done in a particular sprint for whatever reason, it would be idiotic to keep someone assigned to it for the rest of that sprint, yes? Far better for them to work on something else, such as dealing with small bits of technical debt that happen over time, or dealing with smaller tasks that had been otherwise consigned to a future sprint. Aug 11, 2013 at 8:00

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.