The "Three Questions" for Scrum dailies sound to me like a perfect instruction, to waste 15 minutes with useless status reporting:

  1. What have you completed since the last meeting?
  2. What do you plan to complete by the next meeting?
  3. (impediments...)

It often goes in the way of: "Yesterday I did task X, today I will work on Y", or, more often, "I am still working on task Z", on almost every day of the sprint. Sometimes with more or less technical details.

Some people say it's for Check-In instead of Reporting, but is there a difference? Apart from Reporting possibly leading to immediate rating. And if, what is the difference?

These reports every day make little sense to me, as long as there are no important news, or impediments to be bookmarked for later debate/solving. They have a tendency to become 10 or 15 minutes of boredom. Or is there a different meaning in the first 2 of the 3 questions, that qualifies "check-in" in a different way?

  • Did you ask "some people" what the difference is between check-in and reporting? – Robert Harvey Apr 17 '18 at 15:04
  • 1
    @RobertHarvey Does it matter, since they are both wrong? Daily Scrum is not for "checking in" or "reporting". It's for inspecting and planning. – Thomas Owens Apr 17 '18 at 15:25
  • @ThomasOwens: The words matter very little. What sort of "inspection" is going on in a scrum standup? – Robert Harvey Apr 17 '18 at 16:05

Scrum considers the Daily Scrum to be an inspection and planning meeting. The purpose is to inspect the work done against the Sprint Goals and to plan the next day's worth of work. The three questions are just one method of running a Daily Scrum and are not required. The Scrum Master should be coaching the Development Team on an effective way to execute the Daily Scrum such that the objectives of inspecting progress against the Sprint Goals, inspecting progress against the Sprint Backlog, and adapting or planning for changes to be able to achieve the Sprint Goals are met.

The 15 minute timebox is also a maximum length of time. Depending on the size of your team, it may be shorter. A Development Team in Scrum is between 3 and 9 individuals. A Development Team of 9 people should be able to complete their inspection and planning in 15 minutes. A team of 3 may need a shorter period of time to do the same.

Another key element from the Scrum Guide is that the "Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint's work". Some things may come up in the Daily Scrum that require additional work to figure out what to do or may need the involvement of the Product Owner. In these cases, the problem should not be addressed immediately in the Daily Scrum, but by the right people after the Daily Scrum.

If you are simply "checking in" or "reporting" the status of work, I would consider that to be half of what the Daily Scrum is supposed to be. You should also be looking at the Sprint Goals and finding ways to either meet the Sprint Goals come the end of the Sprint or working with the Product Owner to realign the Sprint Goals to something that is achievable. The Sprint Retrospective is a great opportunity to revisit and reflect on why certain problems came up that impacted the team's work and how to prevent them in the future.

  • I usually know that people have tasks taking, for example, half or all of a two week sprint. So if a developer has a task planned for 5 workdays, he will be busy with it, and do no more detailed planning (except for himself). Of course when he goes into details, like "I will today do processing profiles and then the other half of the unit tests", the dailies can get lengthy - and it's only a spoken plan, no written, confirmed schedule. Is the last your intent (kind of lightweight planning)? - I see however, that this may simply be boring to those who are not into this particular task. – Erik Hart Apr 17 '18 at 14:54
  • 3
    @ErikHart Why do tasks that take so long? Product Backlog Items should each be smaller than a Sprint - that is, a team should be able to deliver at least one PBI every Sprint. You should be decomposing these into actionable work on the order of 1ish days. That doesn't mean you need to necessarily put the work into a tracking tool or on a board, but it means you can show forward progress and identify truly blocked work and plan to resolve it sooner. If one person is showing signs up being stuck, the team can identify this and come up with ways to help. It's about transparency in the work. – Thomas Owens Apr 17 '18 at 15:01
  • 1
    Really the +1 is for mentioning the follow up conversations that happen after scrum. It's a chance for the whole team to get insight on what everyone is working on, and it's their chance to shout out "hey, that affects me!" – Greg Burghardt Apr 17 '18 at 15:07
  • Sorry, I confused some things, just changed over from a Kanban team (did Scrum long ago and didn't remember everything, just as developer). I missed the detail planning into tasks and referred to Backlog Items, stretching over 1 to 2 weeks. Those detail tasks also sometimes stretch over several days (then probably planned wrong). – Erik Hart Apr 17 '18 at 16:08

Not a huge amount to go on without knowing the innards of your project, but a few general comments on the points you've outlined:

more often, "I am still working on task Z"

Perhaps the problem here is your stories aren't granular enough - if you find yourself saying the same thing for more than a few days, alarm bells should be ringing. Opinions vary on how big stories should be but as a rule of thumb they should be no bigger than 2-3 days.

These reports every day make little sense to me

Perhaps they don't if the stories are well defined and you're getting through the work and you're on target. You may therefore, want to consider having them less frequently. The process should work for you - not the other way round.

I'd recommend you don't abandon them altogether. These things tend to be harder to arrange second time round if they have been abandoned before - purely due to people filling their diaries with other stuff or not taking the stand ups seriously.

If it is the time it is taking you object to, consider whether it would be better to split the stand up on functional lines or however you choose.


It's not supposed to be reporting, it's a conversation with fellow developers to help plan the day and make sure the team is on track. Maybe they are the same thing, but having the mindset of sharing vs reporting helps keep it simple and useful IMO.

On just about all of the high functioning scrum teams I've been on, almost everyone looked forward to the morning scrum because it was a chance to see the great work being done by our peers.

Some people say it's for Check-In instead of Reporting, but is there a difference? Apart from Reporting possibly leading to immediate rating. And if, what is the difference?

If there is someone in the standup who has the power to do "immediate rating", they should be removed. The standup is for the team only, not management.

They have a tendency to become 10 or 15 minutes of boredom. Or is there a different meaning in the first 2 of the 3 questions, that qualifies "check-in" in a different way?

If they are "10 to 15 minutes of boredom", it's because your team is choosing to make them that way. If your standups aren't working, discuss them in the retrospectives, and find ways to make them better.


THe purpose and value of the event as expressed in The Scrum Guide are missing.

The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog.

The lead in to the three questions was improved in 2017.

The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based.

Status reporting in the Daily Scrum is a simple indicator that the purpose and value of the Daily Scrum event is not understood.

Walking the Board by reviewing each Product Backlog item is often the next step to maturity and provides a better realization of value.


Ideally the Development Team is collaborating throughout the day, perhaps with pair and mob programming, to such a degree that the Daily Scrum event becomes a quick conversation for the Development Team to validate their shared understanding regarding the emergent plan and progress toward the Sprint Goal.


It could be used any way anyone wants. There's probably many traditional managers who adopted Scrum because it sounds cool or they were forced to, but still rely on their old command and control processes. To them, you're reporting.

This is where a team in general or as it relates to a specific project need to examine what they are doing, why they do it and whether or not you're getting out of it what you need. It's about the team getting the project done.

Most programmers like to think they wouldn't let a routine run in their code that accomplished nothing, but then there are those who build things not in the requirements because you never know.

Don't do that with Scrum. The stand ups are seen as a quick and easy way to communicate potentially necessary information. Feel free to get rid of it and/or come up with an alternative. In some cases the team knows when to share information and when not to.

Personally, if I was being required to track everything I'm working on in one system and then had to stand up every day and basically repeat to everyone what I entered, that would get old, but we all know, nobody is reading what's in the other system. The stand up meeting doesn't give you a choice.

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.