Daily stand ups exceeding 15 min

Last post 03:43 pm July 14, 2020
by Jack Daniel Morilla
10 replies
07:40 pm April 14, 2020


I am a fairly new scrum master and the development team has been historically had daily stand ups in which the business analyst or owners of their cases attend the stand ups as optional. I have observed on certain times some developers when talking about blockers they discover or learn that have to ask the Business Analyst some additional questions about the case is working on since he/she learned something while developing the case.
So the meeting ends up between 20 to 30 minutes. I have tried to change this but is not that easy, since BAs are not that available after the meeting so of course the programmer takes advantage that they are present to ask any additional question in their in progress cases. I have tried to 1st limit the stand up and if any questions (blocker)  to take it after we all have have done our stand ups questions as if it is the 16th minute approach, but then most of the people stays on the meeting until it is made a conclusion on the different cases mentioned so it does not matter the order we do things the total amount if time is always exceeding 15 min.


Any ideas how this could we change so that we only do short stand ups and if there are questions on a case maybe to have another meeting to discuss that more in detail with the right involved people? 

08:03 pm April 14, 2020

In addition:

I have thought maybe to hold stand ups only with developers and maybe reserve 20 min on the calendar as placeholder right after with the business analyst?. Like a “sit-down” meeting mainly to ask specific questions? The problem is that we would need each day to update BAs if this meeting is needed or not since it is already reserved in the calendar as placeholder... it will require follow up 

Also I must say that with the Corona virus situation it needs all planning and booking meetings for everything, not that easy as just discussing the case informally right after the meeting at the desk.. 

I would really appreciate some practical ideas?? 

Thank you in advance!


PS.: just to clarify, we have a PO but is mainly to do priorization of the backlog items entered by the business analyst that enter cases or user stories. So the PO of the scrum guide in our company is split in 2 positions, the PO for priorizations and the BAs or also called Value owners that enter the cases and do the refinement with the development teams and final UAT test.  

08:30 pm April 14, 2020

I'm a proponent of the entire Scrum Team being present at the Daily Scrum. I've found that it has a significant impact on the ability of the team to coordinate for the upcoming day and rest of the Sprint. However, it's also important to focus on the core of the event, which is for the Development Team to synchronize.

As far as scheduling goes, I've had success booking the Daily Scrums for 30 minutes. I've even thought about 45 minutes as an option. The first 15 minutes are a strict timebox for the Development Team to synchronize with each other and with the Product Owner and/or Scrum Master. The objectives outlined in the Scrum Guide are achieved here. The remainder of the time is simply to reserve a room (when people are in the office) and block time on people's calendars for additional discussions that need to happen. If a particular individual doesn't need anything, they can simply return to work. If things take longer than that extra 15 minutes or if more research is needed, people are able to ask the questions and then everyone can prepare for and schedule a longer session with the right people.

I do think that there may be optimizations around the Product Owner and Business Analyst roles, as well. This may also include thinking about how you align your Development Teams with the products and services they maintain.

11:58 pm April 14, 2020

Very common occurrence. You can have a fifteen minute Daily Scrum with no more than four people. This is based on my inspection. If I am in a room with more than five people (myself included), it needs to be two separate Daily Scrums. Personally, I don't like large Scrum Teams. So four Development Team members are the right size for me.

You can also facilitate to get each member's thoughts on a whiteboard with each team member's name (or avatar) listed. Repeat this process each day to show many voices are not being heard. They'll get the point. 

08:41 am April 15, 2020

Hey Alejandro,

I think you're resisting the urge to exceed your daily Stand-ups, as you feel they'll screw up your routine. But I don't think that should be the case - if there is a time crunch, I can understand. However, I do find myself in a 30 min+ briefing quite often than not - and it does wonders for our daily schedule.Talk with your team about this, and sort it out.

~Sanjeev Nanda

09:58 am April 15, 2020

BAs are not that available after the meeting

Why not? They are Development Team members, because their collaboration is required if an increment is to be produced. Why doesn't their commitment to the team reflect this?

12:19 pm April 15, 2020

Have you tried sharing your observations and what the impact is during the Sprint Retrospective?

And have you thought about teaching the value of Focus and Time-boxing? Is there a Sprint Goal to focus on during the Daily Scrum?

04:07 pm April 15, 2020

I'm going to have a slightly different opinion on this and it doesn't really follow the Scrum Guide. 

There are a couple of ways to deal with this.  Discuss with the all of the people attending the Daily Scrum, which in your case includes the Product Owner and Business Analyst, that in order to keep this activity effective for everyone, the Development Team needs to quickly go through their planning for the day and that additional discussions will occur after that is finished so that anyone not needed for the additional discussions will be able to leave. After the Development Team has planned their activities for the day and raised any impediments, the necessary people will stick around to discuss.  If that activity takes longer than 15 minutes, then so be it.  You are in essence removing an impediment to the Development Team which is the unavailabliity of the Business Analysts.  If they do not like that suggested action, then have them offer an alternative that will provide the necessary availability and timely responses needed by the Development Team. 

That is the closest I have to a Scrum answer.  My other answer is who really cares if it takes longer than 15 minutes if the end result of giving the Development Team the ability to plan their day in a way that provides the most value and furthers the Sprint Goal of delivering an potentially releaseable increment?  Have you ever attended a Kanban "walk the board" session that is an equivalent of the Daily Scrum?  It isn't a 15 minute timebox. It is a result driven timebox. If the current practice is deliverying the correct results, don't be the Scrum Police and make them change it because it isn't following the 15 minute rule.  

07:56 am April 17, 2020

Daniel, sometimes out of the box answers, are actually the best answers. I really wish that Scrum had a sister program that dealt with open forum organizing, much like a discord group, or an intimate forum. We have a supplemental group that takes care of these very things. Sometimes, one has to deviate from the response, to get the perspective on the answer. Good job! 

10:30 am June 25, 2020

15 minutes of Daily Scrum is only to answer 3 questions. Any development team member needing further discussions give a shout to relevant team member to stay behind for further discussions. Daily scrum finishes within 15 min and time used afterwards is support time to remove impediments.

04:09 am July 14, 2020

My practice as Scrum Master:

1. Daily Scrum is stick to 15 mins, using the template What did you do yesterday, Continue to do today, then Impediments/Blockers.

2. Once all is done, those who have impediments will remain on the Call/Meeting then we will discuss further on the show stopper together with the people who are knowledgeable to resolve the problem.