Skip to main content
Copy edited (e.g. ref. <https://en.wiktionary.org/wiki/don%27t>, <https://en.wiktionary.org/wiki/practice#Noun>, and <https://en.wiktionary.org/wiki/textbook#Noun>).
Source Link

The idea of a daily stand up isn't just to discuss issues, but for the team to which includes the scrum master, the product owner and the rest of the team (devsdevelopers, BAs, etc.) to confirm what they've worked on, are going to focus on during the day and any issues. Some timesSometimes the feeling between the team is 'well, we already know the answers', but the practisepractice and routine of doing this calls out the unknowns and also opens opportunities to say something typically individuals dontdon’t always do (and on time) until they are face to face or being asked about it.

There is no text bookisn't any textbook way of running them, and should be run in a way that drives the best output from the team and the project being worked on. Sometimes the team wont always agree with the scrum master approach and that is okOK, but the scrum master should always ensure everyone is clear on what the lay of the land is for the day.

Some times there is a case where you can't or don't need one for whatever reason. Still you could invite the team together and focus on anything urgent and then cut short.

I would always encourage email commscommunication, but only after the physical  (or virtual) get together. After the team can ping out anything they feel the other team members should know if the need is there (or through any other collaboration method e.g. instant messaging through MS Teams Microsoft Teams, SkypeSkype, etc.).

The idea of a daily stand up isn't just to discuss issues, but for the team to which includes the scrum master, the product owner and the rest of the team (devs, BAs etc) to confirm what they've worked on, are going to focus on during the day and any issues. Some times the feeling between the team is 'well we already know the answers' but the practise and routine of doing this calls out the unknowns and also opens opportunities to say something typically individuals dont always do (and on time) until they are face to face or being asked about it.

There is no text book way of running them, and should be run in a way that drives the best output from the team and the project being worked on. Sometimes the team wont always agree with the scrum master approach and that is ok, but the scrum master should always ensure everyone is clear on what the lay of the land is for the day.

Some times there is a case where you can't or don't need one for whatever reason. Still you could invite the team together and focus on anything urgent and then cut short.

I would always encourage email comms but only after the physical(or virtual) get together. After the team can ping out anything they feel the other team members should know if the need is there (or through any other collaboration method e.g. instant messaging through MS Teams , Skype etc).

The idea of a daily stand up isn't just to discuss issues, but for the team to which includes the scrum master, the product owner and the rest of the team (developers, BAs, etc.) to confirm what they've worked on, are going to focus on during the day and any issues. Sometimes the feeling between the team is 'well, we already know the answers', but the practice and routine of doing this calls out the unknowns and also opens opportunities to say something typically individuals don’t always do (and on time) until they are face to face or being asked about it.

There isn't any textbook way of running them, and should be run in a way that drives the best output from the team and the project being worked on. Sometimes the team wont always agree with the scrum master approach and that is OK, but the scrum master should always ensure everyone is clear on what the lay of the land is for the day.

Some times there is a case where you can't or don't need one for whatever reason. Still you could invite the team together and focus on anything urgent and then cut short.

I would always encourage email communication, but only after the physical  (or virtual) get together. After the team can ping out anything they feel the other team members should know if the need is there (or through any other collaboration method e.g. instant messaging through Microsoft Teams, Skype, etc.).

Source Link

The idea of a daily stand up isn't just to discuss issues, but for the team to which includes the scrum master, the product owner and the rest of the team (devs, BAs etc) to confirm what they've worked on, are going to focus on during the day and any issues. Some times the feeling between the team is 'well we already know the answers' but the practise and routine of doing this calls out the unknowns and also opens opportunities to say something typically individuals dont always do (and on time) until they are face to face or being asked about it.

There is no text book way of running them, and should be run in a way that drives the best output from the team and the project being worked on. Sometimes the team wont always agree with the scrum master approach and that is ok, but the scrum master should always ensure everyone is clear on what the lay of the land is for the day.

Some times there is a case where you can't or don't need one for whatever reason. Still you could invite the team together and focus on anything urgent and then cut short.

I would always encourage email comms but only after the physical(or virtual) get together. After the team can ping out anything they feel the other team members should know if the need is there (or through any other collaboration method e.g. instant messaging through MS Teams , Skype etc).