We all know that everything in scrum is time-boxed. The iterations, meetings, discussions, daily scrum etc. etc... Many of us are struggling to keep these time-boxes. My little advices:
It is very common that the participants may slip away from the real topic and might get into discuss something(related/non-related) which may not help to achieve the goal of the meeting. The moderator can note down the key points and request to have a different forum to discuss them reminding the participants about the goal of the meeting.
An issue which especially happens at the planning meeting or estimation meeting is that people will try to find the solution for the problem. These meetings purpose is to understand the problem rather than finding a solution. People should try to gather information from the product owner to address the story.
This bad habit affects the interest of a product owner for attending such meetings. Keep your focus on asking relevant questions and clarifications to the product owner instead of discussing within the team in these meetings. PO is the prime person for these meetings. So we should not give an opportunity to drive away PO's focus to something else because the team is discussing the story and PO feels it is irrelevant to him/her.
Strictly follow the guidelines for the daily scrum. There should not be questions raised during daily scrum arising situations like person B should speak in the middle of person A's time. I mean, if we scribe the daily scrum word by word, no sentence in the script should end with a question mark. If there are questions please ask them once the daily scrum is over.
Review meetings are meant for explaining what the team has produced during the sprint. Stick to that. If any questions/discussions happens on topics not in the scope of the story, park them as an opportunity to create new stories and continue. All the feedbacks should be scribed and don't go for a discussion on those during the meeting. Discuss them with the relevant people at a different meeting. Never explain each story in its minute level. Instead, the team can ask the interested party to try it and provide the feedback later as the team is delivering a working product. Avoid the technical explanation to the story (what code has been written, whether it is while loop or for loop etc.) unless otherwise it is the scope of the story.
It is recommended that retrospectives focus on process rather than product, but not mandatory. Know the bandwidth of the scrum team on applying the action items that arises during the retrospective. Discuss only the items that comes within that bandwidth. Don't try to dig deep on any of the action point if it takes a long time on discussion. Realize the priority of the action item and schedule another discussion forum on the topic if required.
- Start the meeting with a narration of the goal of the meeting.
- Emphasise on the agreed etiquettes of the meeting like be a good listener, no mobile phones, etc...
- Have a common agreement on what is the time-box allocated for the meeting.
- The scrum master or any team member can act as a moderator-cum-participant.
It is very common that the participants may slip away from the real topic and might get into discuss something(related/non-related) which may not help to achieve the goal of the meeting. The moderator can note down the key points and request to have a different forum to discuss them reminding the participants about the goal of the meeting.
An issue which especially happens at the planning meeting or estimation meeting is that people will try to find the solution for the problem. These meetings purpose is to understand the problem rather than finding a solution. People should try to gather information from the product owner to address the story.
This bad habit affects the interest of a product owner for attending such meetings. Keep your focus on asking relevant questions and clarifications to the product owner instead of discussing within the team in these meetings. PO is the prime person for these meetings. So we should not give an opportunity to drive away PO's focus to something else because the team is discussing the story and PO feels it is irrelevant to him/her.
Strictly follow the guidelines for the daily scrum. There should not be questions raised during daily scrum arising situations like person B should speak in the middle of person A's time. I mean, if we scribe the daily scrum word by word, no sentence in the script should end with a question mark. If there are questions please ask them once the daily scrum is over.
Review meetings are meant for explaining what the team has produced during the sprint. Stick to that. If any questions/discussions happens on topics not in the scope of the story, park them as an opportunity to create new stories and continue. All the feedbacks should be scribed and don't go for a discussion on those during the meeting. Discuss them with the relevant people at a different meeting. Never explain each story in its minute level. Instead, the team can ask the interested party to try it and provide the feedback later as the team is delivering a working product. Avoid the technical explanation to the story (what code has been written, whether it is while loop or for loop etc.) unless otherwise it is the scope of the story.
It is recommended that retrospectives focus on process rather than product, but not mandatory. Know the bandwidth of the scrum team on applying the action items that arises during the retrospective. Discuss only the items that comes within that bandwidth. Don't try to dig deep on any of the action point if it takes a long time on discussion. Realize the priority of the action item and schedule another discussion forum on the topic if required.
