We are a small team of around 5 developers.

We're using a ticketmanagement-system that has a virtual Scrumboard.

On the Scrumboard are several columns. The items on the columns are sorted by priority:

New | Consultation | Working | Waiting | Test & Review | Done

Consultation = We need Feedback from someone outside

Waiting = Waiting for someone or something

We have around 40-50 active tickets while doing a 2 week sprint.

In a standard Scrum-daily usually every developer answers 3 questions:

  1. What have I done yesterday?

  2. What will I do today?

  3. What are my impediments?

Somehow our process is different:

We go by column and then by each ticket in the column.

We do this because of several reasons:

  • this process developed on its own, we did not plan it, it just happened
  • some developers would "space out" when others would talk and not listen. Yes, it's usually just a 15 minute daily, so one can expect that listening for this time should be possible. But since we all work from home, we cant notice if someone is listening or not.
  • when a developer is finished with his 3 questions, he might not listen to the others, since his focus is gone
  • the developer is visible on the ticket, but searching your own name in order to find the tickets you are working on takes a bit of time. There are ways to switch the view, but constant switching the view gets annoying quite fast for everyone
  • if we go by developer, he would sometimes overlook an important ticket while giving his presentation

Going by columns and then tickets feels more "natural", also everyone seems more active at listening, since the next ticket might be his or hers. Also we dont overlook any important detail or ticket. Most of the time the developers indirectly answer the 3-questions this way as well, but not always. This process still feels somewhat superior - at least in our environment!

So should you ALWAYS go by the 3 questions, or should you go by tickets?

Or is there a way to tell when which approach is "better"?

(Maybe this picture might help to understand my questions)

scrum daily 3 questions vs ticket based

  • 2
    While changing the format is no problem whatsoever, I think the fact that the 3-question stand-up is not working is usually a sign of doing something wrong. The focus of the three question with my team is usually interpreted as follows: 1. Did I change anything yesterday which others should know about, or did I find new knowledge about something I want to share? - 2. What concrete parts will I work today, so I can coordinate with others working at the same pieces? 3. Is there anything where I'm having hardships (these could also be personal, not related to a concrete task)
    – Falco
    Commented Aug 17, 2020 at 12:57
  • 6
    And if people are spacing out, or think the meeting is not very productive the first scrum-like idea would be to shorten it and shorten it again until people complain they don't have enough time to tell the important parts - then allow enough time for these important parts only.
    – Falco
    Commented Aug 17, 2020 at 12:59
  • Can you clarify what you mean by "overlook an important ticket"? Commented Aug 17, 2020 at 14:25
  • 3
    Another similar situation to watch out for: If you only look at what's on the board, make sure that really all work is on the board. Otherwise, if you're not talking to every person in each daily, you might overlook work that's being done but hasn't found its way to the board yet.
    – Alex
    Commented Aug 18, 2020 at 8:47
  • 2
    I would challenge the framing as well, why is it necessary to discuss all the tickets every stand-up? is it not sufficient to only discuss those tickets where people are encountering issues or require feedback/assistance? Does the work not get done if you don't talk about it every morning? As an aside, I personally start tuning out as well when people drone on about everything they're gonna be doing or have done, but when you limit yourself to the problems and challenges its much easier to stay focused so that could also be a factor
    – Cronax
    Commented Aug 18, 2020 at 12:21

6 Answers 6


So should you ALWAYS go by the 3 questions, or should you go by tickets? Or is there a way to tell when which approach is "better"?

The 2020 version of the Scrum Guide removed the three questions, while the 2017 version of the guide says this:

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.

So do whatever you think is best or ask your team what they prefer and find more useful.

The three questions are an example of how the daily can be conducted because they focus the discussion on the basic things that you need to cover to coordinate your efforts towards the goal. If you find discussing the tickets a superior approach, then go with that.

Just make sure you don't loose yourself in too many details (you can always discuss in more detail after the daily) and go beyond the time box which in turn will make things transform into a meeting and give people more opportunities to mentally checkout.

  • The daily scrum should be in a box of 15 minutes. So the time should be used carefully. Try to come prepared, try to make your answers clear and "interesting" for the others. Only share IMPORTANT things. You can even just mention, I need help from x, y and z after them daily. Talk only about things which will maybe let the sprint goal fail, avoid the happy path.
    – KargWare
    Commented Aug 31, 2020 at 9:03


Should you walk the board by developer or column? Neither. Both are anti-patterns.

Don't treat the standup as a status pull from the team, and definitely don't use it as a mini-review of the status of every task planned for the whole Sprint. If you keep the scope of the standup to the current day's work, the question of how best to "walk the board" (hint: there isn't one, because you shouldn't be doing that) goes away.

Refocus on Team Coordination

Your question starts from a fundamentally-flawed assumption: that performing a status report on all tickets is beneficial or even desirable in Scrum. It's really an X/Y problem insofar as the team is missing the whole point of the daily standup, which is to perform just-in-time planning and coordination for the current day's activities.

The "three questions" are just a means to an end. In less mature teams, having a guidelines or talking points can help team members identify dependencies between tasks. The intent isn't to provide a status report, though. The goal is always to help the team plan the current day's work collaboratively. For example:

Sandy: Yesterday I worked on embiggening the central widget. Today I need to ensmallen the primary cog, but I need the whatchamacallit from Susan to do that.

Susan: Yesterday I finished the whatchamacallit, so it's ready for Sandy. Today I wanted to work on the frobnosticator, but I'm stuck until the MacGuffin story is complete. Is anyone working on that yet?

In other words, don't use the daily standup to "walk the board." Use it to enable the team to self-organize around the day's work! If the questions help the team do that, great. If not, toss them.

Similarly, only work already in progress or planned for the day should be discussed at the standup. Work in the Sprint Backlog or a pending state is only relevant if it is a dependency of a current task, a blocker for something else, or someone plans to pull it in as work-in-progress today.

If you really want a Sprint status, leverage your Done column and your burn-down chart to determine if you're on track to meet the Sprint Goal. If the status of the Sprint Goal is in question, that probably deserves a separate meeting outside of the daily standup, and most definitely some attention from the whole Scrum Team during your next Sprint Retrospective. At best, walking the board is a stopgap to cover up ineffective communications or missing/invalid information radiators. At worst, it actively prevents the team from collaborating on just-in-time planning by favoring status reporting over interactions between team members.


The three questions approach is focused on the individual, but the board approach is focused on the team and the sprint goals. (Or, at least, the goal at the right hand side of the board.) In my experience, a pitfall of the three questions is when an individual feels they have to prove they have been working. But going by tickets, you may not even talk to every individual.

As I hinted above, which is better depends on your goals.

If the team is cohesive and the board reflects the path to the goal, then by all means, use the board. (I'd suggest taking it further and using the board explicitly right-to-left: putting the focus on getting stuff finished.)

But if the team is new or not yet working well together, or if the board doesn't really represent the goal, then the three questions might be a better bet. The sprint goal might actually be, "get this new team to gel", or "onboard Frankie so she can be effective". If that's the case, you definitely want to make sure everybody has a chance to talk about what they're doing, and what works and what doesn't.

  • Asking the 3 questions (without variation) also kinda get's annoying ... "What have you done today?" ... "What have YOU done today?" ... "And you?". The other approach can have some overhead: the Test + Review-column doesn't change daily (some items get tested by non-IT members who don't test daily), so you have to keep track which ticket you need to talk about and which not. Our ticket-system can show checklists where we enter a date or return, so it's manageable, but its something you need to keep in mind in the ticket-based approach.
    – hamena314
    Commented Aug 17, 2020 at 12:14
  • 1
    If used right the "YOU" can improve the feeling of individual responsibility - the idea that each part of the team tries to help reach the goal in any way they can - if someone has done all tasks which are in his field of expertise, he can try to help others outside of his field. But it requires a certain atmosphere of trust, were no one has to prove something to the others, everyone is giving their best and people are not measured by how much they can talk about what they are doing.
    – Falco
    Commented Aug 17, 2020 at 13:03

Or is there a way to tell when which approach is "better"?

One thing with Agile development is that it offers flexibility to project goals and organization. One thing that you can be flexible about how your dailies are being done is iteratively improve on it. Collect feedback from your team, discuss the daily structure in your sprint retrospective, and don't be afraid to experiment with your team's suggestions.

I currently work in a team where we actually have both approaches - we both have a task oriented daily and a "three questions" daily. The first is ten minute daily between developers to discuss the current board and have space for some technical observations; the second is a fifteen minute daily that is much more centered on the "three questions" in an attempt to have a more humane daily with the broader team.

We had a daily going by developer and their tasks, but we decided to scrap the process for both the reasons you mentioned on focus, time concerns, and lack of a cohesive understanding of the status of related tasks. And yes, constantly filtering tasks by developer was a hassle for us too.

I cannot comment, so I added my two cents as answer.

  • Do you talk about specific technical observations in the first 10-minute daily i.e. following a different board / task-column with special topics, or is it more like small-talk?
    – hamena314
    Commented Aug 18, 2020 at 12:16
  • If you're asking if there are any guidelines to our extra observations during the developer daily, then no, it's more like small talk. When analyzing each task on our board during this daily we have the space to briefly share and discuss some technical hurdles or tidbits.
    – Magmagan
    Commented Aug 18, 2020 at 13:32

If I may suggest: "the three questions" might be "staring at your navel," while you really want them all to be "looking around."

The first thing that I would do is to find a way to group your task-list in some way that conveniently allows you to consider related tasks together in a "business useful" way. (Also, find some functional way to "tag" tasks that might be related to more than one group. In software, everything is usually related somehow to everything else.)

Then, I would ask the team to consider each group along with you, and to help all of you choose(!) what – by mutual and informed consensus – ought to be the team's "three questions for the day."

On the one hand, software developers have learned to acquire a superior ability to focus on whatever is the problem of the day. So to speak, "they know exactly how to dive deep and stay down." But – speaking from personal experience now – it's awful to realize, too late, that you didn't know that your just deep-dived in the wrong spot for the wrong reason and you just got suckered by a hurricane. "Had you but known ..."

And so, the fundamental issue is clear: since developers are – and, must be – "deep divers," who's always sitting in the boat, always dry, always watching the big picture? Watching for sharks? Helping them to know, as they paddle-around on the surface, where and why to dive next? That would be you.

Now – to complete the thought – sometimes those divers will come back to the surface with some important new finding that you couldn't know. Always let the developers themselves contribute "tickets" to your mix.


As mentioned by others, the Scrum Guide does not prescribe the 3 questions anymore. And, to be honest, most daily scrums based on the 3 questions contradict the purpose of the event. When it is orchestrated by a Scrum Master and the team members have to report on their past 24 hours that is in 0% self-organising. It will not result in genuinely inspecting the status of the Sprint and planning the day with the spirit of successfully reaching the Sprint Goal. It should be an internal discussion of the development team where team members are interested in their own success.

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.