Skip to content
December 5, 2011 / KaTe

The Daily Scrum game

Our Daily Scrum is a status report …

Sounds familiar?

There is a false assumption that Scrum says that you have to answer three questions during the Daily Scrum. This is merely a helping hand when a team is starting. Later on, let them work on their own form of the Daily Scrum. Some teams stand up, some sit down, some use their Sprint Backlog, some don’t, some use a token, some go alphabetically, but all of them should use the Daily Scrum for planning. Unfortunately the three questions in some teams lead into reporting to the Scrum Master or the Product Owner who are present. Don’t let that happen. Here, I’m giving you an exercise that will allow your team to find their way to doing the Daily Scrum their way. I call it the DS Cards (DS from Daily Scrum obviously ;).

So how does this work? There are four categories (Links point to PDF files with printable cards):
Word In
Word Out

Now, complete a deck. Depending what is the problem during the Daily Scrum you can omit one or more categories or include more of them:
Too much detail or timebox overrun – omit Details
Too little information or Daily Scrum taking two minutes or less – use all of four categories, you can include more Absurds
Discussion is mainly about what I did outside of work – omit Absurds
Some expressions are overused – use more Words Out cards
Team is gloomy – use more Words In
…and so on.

You can distribute the cards during the Daily Scrum or few minutes before, as some of them require a little preparation. If you have an idea for another card go ahead and comment on this post – I’ll include it in the card files.

Let me know how it’s working for you!


Leave a Comment
  1. Jordan / Dec 5 2011 10:17 pm

    How about not calling at a Scrum, and calling it a Sync, and not doing it daily, but every other day.

    People should worry more about who they need to talk to, and then the communication will flow naturally (during normal work hours), not forced daily conversations.

    Thats my thinking anyway

    • KaTe / Dec 5 2011 10:29 pm

      Hi Jordan,

      thanks for the insight. I see it a little differenlty – communication is not the purpose of the Daily Scrum, it’s more of a byproduct. If it were, it would be pointless, especially with a collocated team which communicates constantly. The purpose is to plan the next day of work based on what has been completed already. Treating it as communication only leads to having a pointless status report and this exercise is trying to bring the planning part back in.


  2. Jordan / Dec 6 2011 11:45 am

    So, assuming you have a board of some kind, why is it that people cannot just pick up tasks from a board, and start working on them, and communicate with their colocated coworkers as needed? They can update the completed tasks on the board, and it saves the whole team time.

    If the team is constantly planning every day, then you didn’t do enough planning when you initated the sprint.


    • KaTe / Dec 6 2011 12:37 pm

      I fully agree with you. In the situation you are describing the Daily Scrum is performed – it’s just not a formal meeting, because there is just no need for one. This is a sign of team maturity and quality – they understand what they need to reach the goal. My exercise as well as the rule in the Scrum is targeted on the teams that are still learning, to help them improve or show that they are incapable of doing quality work. On your blog I have found proof that there actually are people who understand what quality software development is and criticize fashionable words like agile/scrum/kanban not understanding what really is the purpose of those. It does not matter if you’re using Scrum or agile or kanban/waterfall [insert anything else here], if you have a crappy team they will fail and if you have an excellent team, they will just do their job well, regardless of “methodology” or “framework”. Scrum helps you assess which one of those you have.

  3. Jordan / Dec 6 2011 8:35 pm

    Scrum doesn’t help anyone assess. Scrum is just a soup stone. Scrum will just make your environment chaotic enough that you will “see dysfunction”. However, people with vision can see it without regarding too pedantic pop methodologies who’s sole purpose to enrich a few miscreants.

    • KaTe / Dec 6 2011 9:47 pm

      Scrum is a tool, not a methodology. It’s often misused. If there are no other changes behind it – like leadership and organization it will be pointless. If there are people with vision they are usually doing agile without even realizing it. It’s a natural way of working for mature teams and good teams get there without help. Not every team is good though and in many companies there are no teams – only groups of people.

      And if it comes to money – people can make them out of everything – regardless what was the purpose of it in the first place. Religions are a perfect example.

      • Jordan / Dec 7 2011 8:24 pm

        It seems like you’re very good at quoting standard scrum slogans.

        Scrum is a tool — that supposedly exposes change, but it offers no steps in how to fix it.

        Of course, the change could be exposed without Scrum. Not sure what Scrum the tool is actually doing here, that couldn’t be done without it.

        If Scrum was a method to FIX problems, or even covered concretely how to do it, that would be one thing.

        Scrum has banal suggestions about how to do medieval communication, and then claims that will help you uncover dysfunction, but the all important part of how to fix it they don’t cover.

        Sorry, I’m not buying the soup stone stuff.

      • KaTe / Dec 8 2011 8:26 pm

        I see that you are on a crusade against Scrum and agile and I will not try to convince you. You must have not seen the real thing in action, only some crooked implementation without understanding.

        The center of Scrum are short iterations. If you have crappy engineers, they will not deliver anything usable in that time, so this solves one of your problems.
        Scrum has mechanisms for fixing many problems, but the majority of people that are adopting it think that it will solve all of their problems, they will have to do nothing and everyone will live happily ever after. This is rubbish, you will still have to do your job and work hard to gain competitive advantage, so it is said that Scrum will not fix problems for you. Scrum will show you where you are, so that you can take practices from the huge library that is attached to scrum/xp and effectively use the forces you have. Because you can apply scrum to almost every software development project, it’s light enough to fit anywhere. But to work properly (read: all elements in place) you have to have automated testing, engineers that know what they are doing, talking to live people, writing good requirements, having good technical practices etc. This is directly solving problems. The solution will be completely different taking for example a web application and a complex mainframe system. With a mainframe you will probably not use a complete unit test suite, but different integration testing tools, while the web app will have continuous delivery system releasing a new version every five minutes.
        Another aspect is that business thinks that IT people are people you cannot talk to really, because they think and act like robots. Scrum requires direct communication to work, so customers are realizing that there are real people that are actually breathing and talking in understandable language. This way you can just go and ask someone to build a functionality for you while actually talking to them, not writing 20-page PDF using a mysterious business analyst.

        I know this will not convince you. If you’d like to see or join a nicely working Scrum team, let me know, I’ll organize a spot for you in one in Poland.


  4. Jason Morris (@jasonofflorida) / Nov 13 2013 4:30 pm

    Love these games – I’ve just engaged the team with them in order to introduce more games during our morning scrum…to invite others to have fun while achieving business objectives. Great results so far!


  1. Dzień 13 – Standup – Pomiar i adaptacja w trakcie sprintu — Fluid Circle

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: