Scrum daily - Ask the 3 questions per developer or go by tickets?

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.

TL;DR

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.

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.

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.

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.