My team has a new scrum master. The old SM always said that standups were about coordination between the team members and not a report to him. Urging us to help each other if one of us ran into difficulties, to break work items up into smaller pieces, check in and merge frequently, to look out for functionality that could be turned into reusable components.

New SM wants to know how fast we will be done with our items and urges us to review work items quickly. The retrospective is cancelled so we can finish our work.

The old SM always said the standup shouldn't be what he called a status pull and that the team needed to take ownership the work and self organize. I feel that the changes the new SM has made have not been an improvement, but I am unsure how to argue against it.

Is it true that you aren't supposed to report status in standups in scrum? If so why?

  • 2
    Closely related: pm.stackexchange.com/questions/6653/…
    – Todd A. Jacobs
    Commented May 24, 2021 at 21:03
  • 2
    References an older version of the Scrum Guide, but still relevant to this question: pm.stackexchange.com/a/14011/4271
    – Todd A. Jacobs
    Commented May 24, 2021 at 21:05
  • 45
    "The retrospective is cancelled so we can finish our work." Yikes. That's not Agile! The retrospective serves a valuable purpose.
    – nick012000
    Commented May 25, 2021 at 2:45
  • 7
    Lady's and Gentelman I present to you "What happens when you call a Project Manager a ScrumMaster". Please could you confirm who made the decision to cancel the retro so that you could finish your work? If the developers/pigs/peoplpe doing the work decided it was the best way to go then it is still vaguely scrum. If the SM is not seen as some kind of manager/team-lead then we can safely say things have moved far away from Scrum so the title of SM is probably irrelavent.
    – TafT
    Commented May 26, 2021 at 14:03
  • 8
    If your SM cancels the restrospective, then you've got a VERY BAD Scrum Master... if there's one and only one ceremony any Scum Master should value, it's that one...
    – Laurent S.
    Commented May 27, 2021 at 13:23

7 Answers 7


It's not that you aren't supposed to report status in the Daily Scrum. Instead, the purpose of the Daily Scrum is to enable the Developers on a Scrum Team to understand the current state of progress toward the Sprint Goal and adjust their plan to maximize the chance of the team achieving the Sprint Goal before the end of the Sprint.

What the Daily Scrum looks like depends on the team. A team where the Developers tend to work individually and sometimes in pairs would likely have a different structure for a Daily Scrum than a team that regularly mobs. If people are working individually, there may be more emphasis on the current state of work and what people need from each other to get to Done. If the team tends to work as a single entity, there may be more emphasis on planning. Regardless, though, the objective is to assess progress and adapt the plan.

The emphasis on knowing how fast the work will be done seems suspect. When I'm asked to facilitate Daily Scrums, I tend to focus on the age of the item with respect to the team's history. Depending on the tool you are using, you may be able to get information about work item aging and cycle time. Focusing on reviewing items may be a reasonable thing to ask - if you use a Kanban board to visualize the workflow, there's a common practice of walking the board right-to-left and making sure the right-most items progress before taking on new work.

As an aside, canceling the retrospective raises more questions about the ability of the Scrum Master. Retrospectives are not only an important part of Scrum but are the only practice mentioned in the Manifesto for Agile Software Development. If work isn't getting done within the Sprint timebox, the retrospective is the perfect opportunity to understand why and make adjustments for the future. Together, with the changes to the Daily Scrum, I'd question if the Scrum Master truly understands the Scrum framework and the Agile methods.

  • 22
    I'd question if the Scrum Master truly understands the Scrum framework and the Agile methods. This is exactly the problem. They were probably exposed to a perverted version of Scrum in a previous company/project/team and now they are perpetuating what they've learned thinking that they are doing the right thing. I'm allowing the benefit of the doubt here, since I've also seen people doing this practice deliberately because they were responsible with delivery of the sprint with 100% commitment, because of another perverted implementation of Scrum.
    – Bogdan
    Commented May 24, 2021 at 19:01
  • 1
    "there's a common practice of walking the board right-to-left and making sure the left-most items progress before taking on new work." – are items going left-to-right or right-to-left on your board? If they go left-to-right, you want to progress the rightmost (not-done) items first, right? Commented May 25, 2021 at 21:40
  • @PaŭloEbermann Perhaps it's regional, but on every board I've seen, work starts on the left side and moves to the right, where the rightmost column is "done". This is generally true for Kanban boards, but there may be other board formats that don't have columns where a "walking the board" strategy may not be as effective.
    – Thomas Owens
    Commented May 25, 2021 at 21:50
  • 2
    @ThomasOwens It's similar here (except sometimes we are going top-down for spacing reasons), but that's why I was wondering why you want to prioritize left items instead of right ones. From right to left, we are usually trying to finish items which are in QA, then progress ones in review, then help with programming (if needed). Commented May 25, 2021 at 21:54
  • 2
    @PaŭloEbermann Ah, I see. That is my mistake. The rightmost items are supposed to be prioritized. I'll edit now. Thanks.
    – Thomas Owens
    Commented May 25, 2021 at 22:09

TLDR: You don't have a Scrum Master

Repeat after me: The Daily Scrum is not an update-to-management meeting!

Your Scrum Master(SM) is acting not as a SM, but as a manager.

The problem is, the SM is not supposed to be a manager. Take a look at the described duties of the SM. Notice the complete lack of anything along the lines of 'track the progress of the project and react accordingly'.

To answer your actual question

Is it true that you aren't suppose to report status in standups in scrum? If so why?

It depends. Again from the Scrum Guide (emphasis mine):

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. The Daily Scrum is a 15-minute event for the Developers of the Scrum Team.

So... is the Daily Scrum intended to reveal progress? Sure. But it is supposed to be a peer-driven meeting to get the Team on the same page. You are not supposed to be reporting to anyone (see link above)!

By far, the absolute most alarming point in your post is

The retrospective is cancelled so we can finish our work

Problems that jump out to me:

  1. The Retrospective is, in my opinion, the single most important meeting in Scrum.
  2. Part of the Scrum Master's job is to ensure all Scrum meetings are held properly.
  3. The Scrum Master's job does not include determining how the Team gets work done. That responsibility is held by the Team.

You do not have a Scrum Master. You have a manager.

As for what to do...

Is s/he your actual manager (or has the support of such)? If no, the solution is simple - ignore him/her. You need a Scrum Master - so consider stepping up. You take on the role of Scrum Master. You conduct the Retrospective and Daily Scrum. Bring this up in the Retrospective first (ideally not while the not-SM is there, because unless the the not-SM is also a developer, s/he is not actually part of your Team) and discuss this. Then, when questioned, simply instruct the not-SM that "during our Retrospective, we determined that the current biggest blocker was the lack of a Scrum Master. So I stepped up, and we are now enacting Scrum as the organization requires."

If s/he is your actual manager, things get thornier. But it's your job to make him/her aware of the pitfalls of not having a Scrum Master and having a boss, claiming to be a Scrum Master, telling you to not do Scrum. The Scrum Guide will be your friend during this conversation - it is the only actual, de-facto authority on Scrum. The not-SM's actions are having an impact on the business, and as an employee, when you're unable to fix a problem yourself, it's your job to make your boss aware of it (even when your boss is causing the problem). After that, though, you need to either abide by your boss's instructions, go higher up the chain of command (be careful with this), or vote with your feet.

  • "After that, though, you need to either abide by your boss's instructions, or vote with your feet." – Well, you could go to your boss's boss, but then you'd better be darn sure that you are right and they are wrong, and that you have the backing of your Team members. In fact, either action (go to your boss, go to your boss's boss) should ideally be done by the Team as a whole. Commented May 25, 2021 at 23:06
  • @JörgWMittag I'd argue it's not necessarily necessary for just going to your boss - keeping the boss informed is generally part of an employee's regular duties; it shouldn't need the support of the Team. I agree that going up the chain of command is an option but a risky one and should only be done with proper support, though; that's a good point.
    – Sarov
    Commented May 25, 2021 at 23:09
  • 1
    This post sums it all up for me. You've got a good, ol' fashioned "Command and Control" management going on. Sounds like you need that Retrospective more than ever! Commented May 26, 2021 at 8:45
  • 1
    Regarding the second-to-last paragraph, I'd say that advice could be pretty dangerous, depending on who decided that the "Not-SM" is the SM. If your boss (or someone above your boss) appointed said person as SM, then the proper course of action would seem to be to address that that person is not actually acting as an SM (either to the not-SM or to your actual manager) rather than to appoint yourself as the SM without consulting your manager first. "Not-SM wasn't doing their job well, so I decided to appoint myself to their position" isn't going to go over well in most situations.
    – reirab
    Commented May 26, 2021 at 19:51
  • 1
    @reirab Fair point I suppose. I added " (or has the support of such)" to address.
    – Sarov
    Commented May 26, 2021 at 20:01

The SM's job is to make sure that the ceremonies happen, not to tell the developers how to conduct their meetings. Daily stand-ups are supposed to be run by and for the development team.

While there are no absolute rights or wrongs in stand-ups, I do think it's a waste to use a whole-team meeting to report status. Status can be read from a Kanban board or collaboration software at any time. Using the time to talk about what comes next surely makes more sense than talking about what is past because people can then react, offer assistance, advice or just be reassured by knowing something is being addressed.

Cancelling the retro surely is not likely to encourage collective ownership and self-organisation. Skipping the retro in order to complete planned items might make sense sometimes but you could take account of that at the next sprint planning meeting and try to make room for the retro in the following sprint.

  • 3
    I'd add the question of reporting the status to whom? Anyone other than a developer isn't even supposed to be at the stand-up, and that includes the SM who is only supposed to be there to facilitate, not participate.
    – Erik
    Commented May 25, 2021 at 6:35
  • 4
    This applies even more so, if the status is as expected. "Today is Wednesday, and I am 40% Done with my task for this week" is not news: Wednesday morning is exactly 40% of the week, so why would the status be anything else? "I am only 10% Done because of unexpected problems, A, B, and C, and it looks like I will not be able to finish the task I have committed for this sprint" is a whole different story, though. As is "I am 90% Done with my task because I discovered a framework function that already does what we need, anybody need to bounce some work my way?" That is interesting, but that's Commented May 25, 2021 at 11:17
  • … not really a status report. Commented May 25, 2021 at 11:17

Slightly different statement of the above - I agree with the other answers, but will share a different perspective.

If you are reporting status in a meeting of N people, then that status is of no value to N-2 people. most of the people in that meeting are being paid to stand around and act like mannequins. A close friend of mine uses his daily standup meeting to do his daily workout because he is required to be (virtually) present, but his participation in the meeting is less than 2 minutes. So while everyone else is doing status reports, he is doing pushups and situps and other exercises.

And at least in my experience, there is a strong incentive to obfuscate status. My current manager's status meeting is absolutely useless because everyone uses as many acronyms and allusions as possible. Psychologically/bureaucratically, if anyone other than the manager understands the status, then there is a risk that they will engage with it and drag you into a turf war/empire building contest. On the other hand, if your update is intelligible only to the manager, then you are clearly elite. The third dysfynction (anti-pattern) is that status meetings lead to people trying to solve problems - which is a horrible antipattern that always results in half informed people offering half informed advice, generally confusing issues and wasting more people's time. A 30s status update can be transformed into a 10 minute exploration of a non-solution by a group of people who aren't responsible stakeholders.

While managers are required to maintain situational awareness of all the efforts under their purview, the only excuse for a mass status update is to stroke the manager's ego. In every other sense, it is more effective to approach each task lead and discuss the status of the task/product/deliverable, and if there are interconnections to explore, schedule an ad hoc meeting with an agenda focused on the problem.

I don't like scrum; I've made that clear across PM.SE. But if your team has the commitment to actually do scrum - to identify actions, blockers and dependencies, then the scrum meeting serves as a locus for self-organization. But the mindset is different; status meetings are

"Behold oh powerful Lord the valuable services that I provide and recognize me among all these lesser vassals"

Scrum meetings are:

This is what I'm doing to advance our cause; I'm proceeding slowly because someone borrowed my lawnmower - if anyone could loan me one for 3 hours, I could get back on track. I'd also like anyone's advice on how to X, but contact me outside the meeting...

Note the focus on us, on our goal and on coordinating resources to find solutions. Nobody's ego gets stroked.

Which is why Scrum is doomed; scrum is self-organizing, and organizations are organized to promote egos first and produce products and services as a secondary effect.


Other answers cover why the Daily Standup shouldn't be a status report to the Scrum Master, but there's a detail missing: If you need a Daily Standup for the team to know the status, then your information radiators (specifically your board that shows in-progress issues) are either not always up to date, not trusted by all team members to always be up to date, or not visible enough.

You shouldn't need a teammate to tell you every day what they're working on, you should be able to see that clearly on the board. Then why does the Daily Standup exist? To have a talk around those issues, not to read the board out loud.


Career-oriented advice: It just doesn't matter. I would conform to the SM's request. I would de-escalate as much as possible. I would report it only as normal job duties require, and with a goal of just being truthful, nothing more. Concentrate on getting your part of the work done. If there is a 'roadblock' to your work outside your control, notify the appropriate people. De-escalation is the key from a career perspective. "Vote with your feet" is then always a backup plan, depending on how strongly you feel about it. The theory behind scrum groups is of interest, but from a practical POV, retaining your job is much more important. "Been there, done that"....


To me it sounds like a lazy Manager updating his team's status, rather than a scrum meeting. It also sounds like Team Meetings at some companies I have been at.

But you have to wonder what would happen if the term Scrum Master was retired, and replaced with something like team coordinator?

On the other hand, remember the Golden Rule. He who has the gold, makes the rules.

Agile is a framework and Scrum is a tool to increase productivity. If Scrum and Agile do not work at a company, then Management will bring in the next game for managing people.

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.