Our daily stand up meeting

Most developers make notes about what they will talk about, simple text list with done and to-do section. Tickets they worked on are listed there.

Is there a way to simplify this, drop the notes and use JIRA for daily standup meeting?


Developers want to see tasks they worked on grouped in done and to-do sections. This is a problem because a task assigned to a tester does not have a developer that worked on it as an assignee anymore.

Any ideas or feedback how to use JIRA for a daily standup meeting are super welcomed!

  • Can you clarify what you mean by "use JIRA for daily standup meeting"? The daily standup meeting is an actual face to face meeting. Are you suggesting replacing the meeting with a tool? Can you clarify? I'd like to answer, but I don't want to make assumptions about what you mean. Thanks.
    – jmort253
    Commented Mar 3, 2016 at 10:19
  • The ultimate goal is be to use JIRA to back our daily standup meeting. So the developers see an overview of tasks they will be talking about during the meeting. Commented Mar 3, 2016 at 10:36
  • Why do you want to add more processes? The daily should be an quick face-to-face status check not taking more then 15min. We preform the daily in front of the scrum board so that they see the active sprint status. If you don't have an real board then you can show the Agile board from Jira of the team on a monitor. But documenting meaningless notes is a time waste in my opinion. The only notes that should be made from this meeting are the impediments found. Commented Mar 9, 2016 at 8:41

2 Answers 2


If developers can't remember the tasks they're working on, then this could be a symptom of two possible problems:

1. There is too much WIP

that there is too much WIP (work in progress) occurring at any given time. Agile methodologies like scrum encourage teams to focus on getting things to the done state as quickly as possible, and working on more than one thing at a time by definition means that you'll get one thing done a lot slower, since effort is expended across the different tasks instead of laser-focused on one.

As an aside, there's also a psychological effect as well, which you can read more about in the article, Multitasking is Killing Your Brain. Additionally, there's a cost to context switching between tasks where it takes a person some time to recall exactly where they left off in the other task.

This effect is similar to what Jeff Sutherland mentions in his book, Scrum: The Art of Doing Twice the Work in Half the Time:

It took twenty-four times longer. If a bug was addressed on the day it was created, it would take an hour to fix; three weeks later, it would take twenty-four hours. It didn’t even matter if the bug was big or small, complicated or simple — it always took twenty-four times longer three weeks later. As you can imagine, every software developer in the company was soon required to test and fix their code on the same day.

As you can see, the cost of context switching is harmful in many areas, and even Joel Spolsky identifies with this in his blog, Joel on Software

"It's easier to fix bugs the same day you wrote the code. It can be very hard and time-consuming to fix bugs a month later when you've forgotten exactly how the code works." - Joel Spolsky, CEO/Founder of Stack Overflow

While you're not specifically mentioning bugs, the idea is similar in that switching tasks involves not only loss of productivity but forgetfulness as well, since there's a limit on the amount of information we can keep in short term memory at any given time.

In short, Cronax's answer is solid. Make sure you have a big screen. That's what we do when we need the sprint backlog to be visible to multiple people, but the problem you're facing can't be solved by technology alone. I strongly suggest taking a look at the amount of work people are doing and make sure they only have two "cards" to talk about in the daily standup:

  • The card which they worked on yesterday.
  • The card they will work on today.

2. Tasks are broken down so they're too small

If you're sure that multitasking isn't the problem, then consider that tasks may be too small. Ideally, since each task, according to scrum, should be something that can be completed in a day, consider re-examining how the team breaks down tasks. The problem could also be not that people are taking on too much work but perhaps that tasks are simply too small. Larger tasks may be easier to remember than ones that are broken down so small that 8 can be done in a day. One is always easier to remember than eight.


This depends on your setup. In one of the teams I have been a part of we had the scrum board completely digital on Jira and it was the 'single source of truth'. We had a sufficiently sized screen to stand around where the digital scrum board could be displayed and still be readable. This was obviously not divided into separate people, but standing in front of the board and looking over all the tickets, the developers would remember what they did last time and could look at what items were still 'to do' and 'in progress' to pick out what they were going to do that day.

Without these facilities (having the scrum board only in Jira and having a way to display it so that everyone involved in the stand-up can easily see and read everything) I don't think this will succeed. If the main board is physical and there is a copy in Jira then people will often forget to update one or the other, potentially leading to problems. (Before the screen, we had two developers pick up the same task independently because one grabbed the physical ticket while the other took the digital one.)

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.