Agile - Daily Scrum

How we do a Daily Scrum at Way Seven Technologies.

Get Started. It's Free
or sign up with your email address
Rocket clouds
Agile - Daily Scrum by Mind Map: Agile - Daily Scrum

1. Why

1.1. Focus The stand-up should encourage a focus on moving work through the system in order to achieve our objectives, not encourage pointless activity.

1.2. Synchronisation Development Team to synchronise activities and create a plan for the next 24 hours.

1.3. Progress Inspect and adopt. The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog.

1.3.1. People and representatives from various areas (e.g., marketing, production support, upper management, training, etc.) wish to know about and/or contribute to the status and progress of the project. Communicating status in multiple meetings and reports requires a lot of duplicate effort.

1.4. Status Status is about answering a couple questions; * How is the work progressing? * Is there anything else interesting that the team should know?

1.5. Team Effective teams are built by regularly communicating, working, and helping each other. This is also strongly tied with team members helping each other with shared obstacles.

1.6. Good Start Good Start means that the stand-up meeting should give energy, not take it. Energy comes from instilling a sense of purpose and urgency.

1.7. Improvement We can’t fix problems we don’t know about so a large part of stand-ups is about exposing problems to allow us to improve. Improvement is not just about problem solving though. Sharing better techniques and ideas is also important.

2. How

2.1. What should be covered by each developer

2.1.1. Questions

2.1.1.1. What did I achieve yesterday that helped the Development Team meet the Sprint Goal?

2.1.1.2. What do I hope I will achieve today to help the Development Team meet the Sprint Goal?

2.1.1.3. Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

2.1.2. Reference board task

2.1.3. 30 seconds per developer

2.1.4. Arrange offline meetings

2.2. Use Task Board

2.2.1. Make task board transparent.

2.2.2. Should be up to date after standup, until next standup.

2.2.3. Everyone should reference tasks on board, from right to left.

2.2.4. Let everyone to update his task board.

2.3. Same time, same place, every day, anyone can join (managers, architects, product team, etc. to observe).

2.3.1. Anyone who is late without either prior warning, a super excuse, or an extremely funny excuse (that induces laughter from every team member) needs to make a financial contribution to the late jar (this can go toward an agreed-upon charity).

2.3.2. Your daily scrum should look like a nice tight circle.

2.3.3. Who

2.3.3.1. Scrum Team

2.3.3.2. Include architects

2.3.3.3. Include managers

2.4. Stand-up

2.4.1. The simple act of standing provides the team with a sense of liveliness to help kick-start the day, and it also ensures that the session stays short and sharp to prevent aching legs!

2.4.2. Form nice tight circle (or semicircle around the task board) rather than an amorphous blob.

2.5. Order

2.5.1. Last Arrival Speaks First

2.5.2. Who is next

2.5.2.1. Pass the token

2.5.2.2. Take a Card

2.5.2.3. Round Robin

2.5.2.4. Walk the Board

2.5.3. Work Items Attend?

3. What

3.1. The Daily Scrum It is a 15-minute time-boxed event for the Development Team to synchronise activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one.

4. Tips

4.1. Use tokens

4.1.1. Use a small soccer ball that gets passed around from team member to team member in any order; anyone who isn’t listening (or is a terrible soccer player) will get a little embarrassed as the ball slips through his or her legs.

4.2. Reporting

4.2.1. Not all forms of reporting will be, nor should be, covered by the stand-up format. For example, overall project progress would be better communicated with a Big Visible Chart such as burn-down, burn-up, cumulative flow diagram, etc.

4.3. Encourage autonomy

4.3.1. Ignore the ScrumMaster

4.3.1.1. The daily scrum is supposed to be an opportunity for the group to briefly “socialize and synchronize.” It is not a roll call or micromanagement session where the team reports into the ScrumMaster and/or product owner. I often find that some team members get into the habit of directing their update to the ScrumMaster only. If you notice a team member addressing the ScrumMaster without making eye contact with anyone else, a tip is to start slowly turning around or looking up at the ceiling — I have found that the habit is quickly broken with this physical cue.

4.3.2. Rotate the Facilitator

4.4. Questions to ask Development team

4.4.1. Everything goes by the plan?

4.4.2. No problems and no delays?

4.4.3. Anyone needs help?

4.5. Participants and Observers

4.5.1. Product Owner is not part of the Scrum team. Therefor he can can only listen, watch and wonder what's happening.

4.5.2. Managers

4.5.3. Architects

4.5.4. etc.

4.6. (Don't) Use Stand-up to start the day

4.6.1. Use the Stand-up to Start the Day. With flexible work hours, not every team member will arrive at work at the same time. A common practice with “flex-time” is to use a set of core working hours. The start time should be at the start of these core working hours. Similarly, if team members need to arrive later for personal reasons (e.g., need to drop off kids at school), the start time should be set at a time so that everyone can attend. There may be a tendency not to work on any project-related tasks until the stand-up.

4.7. Keep it close & loud

4.7.1. The stand-up should be more of a Huddle than a meeting. If it's difficult to hear, bring everyone closer. Beyond allowing for a more relaxed speaking volume, being physically closer tends to cause participants to be more attentive on their own. Being able to stand physically closer is also an expression of greater trust within the team. If the stand-up is a new thing, it's usually enough to use hand gestures to wave people in and say something to the effect of “Let's bring it in”. If the size of the circle has been established for a while, consider explaining the reasons for closing the circle before trying to shrink it.

4.8. Signal the End

4.8.1. After the last person has spoken, the team may not immediately realise that the meeting is over. The gradual realisation that it's time to walk away doesn't end the meeting on a high note and may contribute to Low Energy.

4.9. Something is smelly

4.9.1. Focused on the Runners, not the Baton People are too focused on what they are doing but neglect to consider whether their activities are actually progressing the work. Reframe the stand-up such that the Work Items Attend.

4.9.2. Reporting to the Leader

4.9.3. People are Late

4.9.4. Stand-up Meeting Starts the Day... Late

4.9.5. Socialising & Gossip

4.9.6. I Can't Remember

4.9.7. Story Telling

4.9.8. Problem Solving

4.9.9. Low Energy

4.9.10. Obstacles are not Raised

4.9.10.1. There may be several reasons for obstacles not being raised. Not remembering, high pain threshold, lack of trust in raising issues (because Obstacles are not Removed), no convenient way of raising issues, etc. The facilitator should take care to encourage people to raise obstacles. Introducing an Improvement Board may also provide a less confronting medium. Retrospectives are an effective way of discovering the underlying reason why Obstacles are not Raised.

4.9.11. Obstacles are not Removed

4.9.12. Obstacles are Only Raised in the Stand-up

4.10. Check questions

4.10.1. Are people energised?

4.10.2. Are people sharing problems and ideas?

4.10.3. Are people focused on our objectives?

4.10.4. Are people working together as a team?

4.10.5. Does everyone know what’s going on?

5. References

5.1. http://martinfowler.com/articles/itsNotJustStandingUp.html

5.2. https://www.axisagile.com.au/blog/planning-and-metrics/outstanding-stand-ups/

5.3. http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf