We are in our 10th Sprint right now, and I can see a pattern during dailies.

When a person is doing his or her speech which involve no one else and when his work is a little bit difficult to grasp technologically, then no one really cares about what is being said by him/her. If no one really pays attention then it defeats the whole purpose of the session.

How do you make to keep this meeting intelligible for everyone?

  • You may want to change audible to accessible... Commented Mar 30, 2012 at 14:23
  • @xsace - You sort of answered your own question. If your problem is that things get too technical, then ask participants not to get too technical and consider their audience. :)
    – jmort253
    Commented Apr 1, 2012 at 3:39

5 Answers 5


Technical people like to talk about technical things. If they are asked to tell something with unknown purpose, they often drift into technical meanders, as they feel safe in it. So I assumed that people didn't feel if it's valuable to the others of what they say.

What I did was a little workshop on what to tell during the standup. On the workshop I asked each team member to answer the question "what would you like to hear during the standup, so it would valuable for you?", and write it on a post-it. Then we sticked all post-its on a wall and grouped by similarity. It turned out, that there were 4 valuable pieces of information for everyone, 1 only for tester and 1 only for architect.

I printed those 6 questions and sticked in a visible place, so everyone could see it during a standup.

  • I like the idea of the workshop. i'll try that
    – xsace
    Commented Apr 2, 2012 at 14:58

Let's assume that your daily scrum is:

  • timeboxed
  • limited in discussion to: blockers, today's plan, yesterday's accomplishments
  • it's in a huddle to avoid issues of communication over distances
  • everyone's standing up together (there's nowhere to run! :) )

If all that is true, and one (or more) people are telling stories AND/OR there is problem-solving going on inside this timebox, then the scrum master needs to keep each person on point (or, on those three points).

There's no reason anyone should be going into great details in the meeting. If the information is important to other development, or could potentially be a blocker or otherwise cause issues for other team members, then the person could simply say "I worked on X, it is a bit complicated and affects the work of team members A and B, so we need to have an conversation after scrum."

The scrum master might need to reset the ground rules for the whole group, or could just have a quick chat with the person who is talking far too much.

  • 1
    +1 The SCRUM is simply an overview of WHAT nothing to do with the HOW. Try to reign in the tech talk(er) by asking everyone to stick to the story/feature they are working on and never which list<T> implementation they are using. Even the blocking issues should stick to the feature level as in "I cannot work on X because I need Y from Joe". Commented Mar 30, 2012 at 14:22

Try focussing on issues or blockers, rather than just talking about what people have done the day before.

e.g. "I'm stuggling with XYZ story and need some help"

This encourages people to listen out more for things they can help with.


This is very common. I came across people who liked to talk "geek" during scrum as it made them feel more important or they were frustrated with something.

This needs to be avoided as testers, designers and other team members who are non-developers may be present during the scrum.

Scrum should go on for few minutes (depending on size of your team) and it should highlight problems (if any). We have 12 developers and morning scrum goes on for about 3-5 minutes.

If somebody wants to talk "geek", then maybe it makes sense to organize "mini-scrum" within front-end, server side or database teams. This way they can all discuss their problems and share their achievements.

Some may say that it's important share your achievements and plans for the day, but from what I have seen, database team doesn't care about front end achievements, front end team has no idea about reporting, both front-end and database teams can't care less about new deployment script for server team, so just leave it out of morning scrum :)


Try to put the daily scrum right before lunch time and don't let it go past the 15 minutes. I have been using different timers to make this work. Only in seldom cases the 15 minutes are not engough, especially if you divide the time to the team members equally by such a timer. With putting the timer on a place where everybody could see it - this is really helpful. Everybody sees the time that one has left...meaning has the right to speak. This time barrier is it which suprises me again and again...how the team members are getting better to say only the status and the necessary stuff and leave the discussions away. There are plenty of timers out there...just google for daily scrum timer, time keeper... in apple or playstore Despite of having the scrum in time and therefore make it more efficient and the people come because they know it lasts only 15 minutes...I am searching here in this forum for sth like gamification or fun factors in daily scrums? (I think I am going to ask this question)

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.