Should a Scrum team be tracking the daily commitments each team member makes during the Daily Scrum? We write them down in a kind of a mini task manager, and then we mark them as done during the work day.

Is there any benefit to this process? Or is it a drawback and an unnecessary burden?

  • 1
    Your question was edited to prevent closure as an opinion poll. Please feel free to continue to improve the question if necessary.
    – Todd A. Jacobs
    Commented Mar 2, 2016 at 16:46
  • 1
    Why are you making commitments during the standup? (I assume that's what you're referring to). If I'm not mistaken the standups are to briefly state what you've been up to, what you plan on doing and what has been a hindrance.
    – Lee
    Commented Mar 2, 2016 at 17:42
  • What happens if a task takes longer than expected or a higher priority interruption takes precedence? Would team members be held accountable for missing their daily "commitments" then? If not, they aren't really commitments (and IMHO, daily commitments are a very bad idea). If so, that sounds like a horrible environment. Commented Mar 2, 2016 at 18:13
  • @Lee these daily commitments are actually the answers to the "what you're going to do today?" question that's part of the daily scrum.
    – Sebastian
    Commented Mar 3, 2016 at 7:22
  • 1
    @mamoo before I could enter a discussion with my manager about tracking daily commitments, I needed to know what the PM community thinks about this process - and, thanks to you guys, I managed to convince him that it's totally pointless :)
    – Sebastian
    Commented Mar 8, 2016 at 6:34

4 Answers 4


Coordination/Collaboration, Not Formal Task-Tracking

While the Scrum Guide used to refer to the stand-up as a commitment meeting, it currently says:

The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours.

The purpose of the daily Scrum is not to hold people accountable or to perform a status pull. Rather, it is intended to provide a forum for members of the Development Team to coordinate the current day's increment. The notorious "three questions" are simply guidelines; the format of how the information is presented is not strictly prescribed by the framework.

When done properly, the stand-up helps the team to collaborate effectively. The information shared during the daily scrum informs one's teammates about:

  • What work is ready to be pulled into another team member's queue.
  • What resources are required from other team members to perform a task.
  • Impediments that the team needs to swarm over or route around.

Formal Task-Level Tracking is a Project Smell

Because the goals for the stand-up are coordination and collaboration, it is expected that the team members will informally track the pieces of the day's increment that impact them. Turning daily task-tracking into a formal ceremony serves no purpose other than micromanagement.

It should be clearly evident on a day-to-day basis whether user stories and tasks are progressing or blocked. If the volume of daily work-in-progress is such that detailed formal tracking becomes necessary, that is generally a "project smell" that indicates a process problem with the team's Scrum implementation.

Common problems that can cause this smell include, but are not limited to:

  • Treating the daily scrum as a status pull.
  • A team that has over-committed the volume of stories accepted into the Sprint.
  • A team that doesn't enforce sensible work-in-progress (WIP) limits.
  • A team that assigns tasks to individuals, rather than treating user stories as a collaborative process with collective ownership.
  • A process that values fine-grained task tracking over story-level "done" or "not done" status.
  • A process that is too task-focused, rather than focused on achieving a defined Sprint Goal.

There can certainly be other reasons as well. The important thing is to clearly identify why the team (or more likely the stakeholders) need or expect this level of tracking or status reporting. That's the real problem to be solved, and is most likely a communications or transparency problem within the current Scrum implementation.

  • 4
    Specifically, the only benefit (if you want to call it one) to formally tracking it would be to hold people accountable for missing the commitment. Truth is, you don't need that. You can easily tell the underperformers without formal tracking. Their updates are incredibly vague, progress isn't made, and blockers aren't really identified. You don't need to record-and-playback the meeting to know who is missing their daily commitments.
    – corsiKa
    Commented Mar 2, 2016 at 20:07

Tracking the daily commitments each team member sounds like micro-management at its best.

The exception would be for a very short project, or for a tiger-team trying to solve an emergency.

When you track daily commitments, either the larger chunks are being ignored (woe to the project) or else they are being unnecessarily broken down into meaningless chunks to charm the project manager. The next step is either resentment from the team or them turning this into a joke. Either way you will lose control over the team.

  • 1
    "micromanagement at its best" should probably be "micromanagement at its worst" since micromanagement is hardly to be considered a good thing
    – Cronax
    Commented Mar 3, 2016 at 10:31

From the process point of view there is nothing wrong with it, because this is the closest thing you have for tracking. However, it may harm the team members on the personal level, and can easily lead to micro management.

They may feel an unnecessary pressure on themselves in order to keep the commitments, even if it is not possible to finish the task in a day. This may lead to burnout. Additionally, team members may pick only those tasks that are easy to do in a day and won't pick hard tasks so that they can keep their commitments.

Either way, the strict daily checking may lead to internal conflicts and failed sprints because of the unnecessary pressure and avoidance of failure. That's why we tend to have iterations or sprints as the shortest check period so that the team has space to deliver in its best way.

If you feel that your team is slow or does not keep promises, find the root cause; mentor them to be better at estimation, task breakdown, or even at retrospectives. A very strict daily reporting will show some results in the short term, but nothing good in the long term.

  • "and can be easily lead to"?
    – user
    Commented Mar 3, 2016 at 14:50

I'm doing commitments in my daily standups. I track them only informally. I don't know whether others track them, but I do use the sentence "I commit to finishing X".

I got tired of listening (and often saying) "Yesterday I worked on X. Today I’ll continue working on X. I also worked on Y, and I'll work a bit on Y and Z today, too. Probably, I finish all of them by the next daily standup, this time for sure..." Repeat this for 5-10 team members and for each 3-5 tasks. It's just a big ball of empty promises and hand waving.

I commit to the very minimum I want to finish that day. I don't fill up with my daily with tiny tasks. One thing I'm committed to and I want to achieve that day. This helps to stay focused during the day. If everything is high-priority, nothing really is.

Most often my daily commitment's a small thing as people (including me) greatly underestimate how much effort completing a task in an official setting requires. People forget about manual tests, unit tests, merge reviews, code updates, deployment.

I'm pretty sure it wouldn't help if we enforced this from other members, too so I wouldn't track it formally, for every member of the team. These initiatives should come from the individual, otherwise, some members will feel uncomfortable or make up fake, low-value commitments.

  • It sounds like you need to limit your Work-In-Progress and Focus on one story until it's done. That's already pretty much agile. No need to invent something new or go back to "commitment" (which was removed for example from the Scrum Guide, because it sounds unhealthy. You cannot commit to a result, you can only commit to working to the best of your ability towards that result).
    – nvoigt
    Commented May 22, 2019 at 7:36
  • That's a good point, limiting WIP items could have helped that team. Commented May 22, 2019 at 11:43

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.