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

Question

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)

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.