Daily Stand-Up |
Overview
The Daily Standup is a brief check-in meeting for the Dev Team at the beginning of each day that insures that all progress and potential obstacles remain public, transparent, and therefore accurate.
Attendees
All members of the Dev Team, including the Scrum Master attend. The Scrum Master insures that the event is time-boxed and that the objectives are met, but the team members themselves run the meeting.
Objective
The objective of the Stand-up is quite simple: to keep everyone on pace and to let the team know right away if anyone or anything is falling behind. It follows, therefore, that the stand-up meeting also insures that problems and potential problems can be addressed so that delays are prevented or mitigated.
Timing
The Daily Stand-up occurs daily, and usually in the morning, though this can be adjusted to maximize team productivity. It is time-boxed at 15 minutes.
Important Considerations
The Stand-Up aims at addressing what work is being tackled in the next 24 hours. Members can give an update on what was accomplished in the last day, but details should be kept to a minimum. Focusing on what is to be done helps the team keep a proactive mentality and focus on solving immediate problems. This is intentionally a very short, though high-frequency meeting. The Scrum framework includes highly intentional meetings. If run well and well-timeboxed, they should prevent other, less efficient and more open-ended meetings. If not, they can quickly come to represent a huge amount of accumulated time per week that is not spent on development. Other topics should be kept to a minimum.
The Process
Sprint Planning begins with the PO explaining the general goal of the upcoming sprint, i.e., what the resulting product increment will be. This will be based on the items at the top of the Product Backlog, which the PO will also introduce. The Dev Team members will have the chance to discuss their understanding and request clarification as needed. The Dev Team will then estimate the Stories under consideration and give final feedback on what is actually possible to achieve during the sprint.
Planning Poker
Estimating effort/complexity is subjective. When it comes to determining how much work will be needed to build/accomplish something, everyone’s impression is different. Not only do different people notice and/or focus on different aspects of the challenge, but some people will always skew lower or higher than others in their estimates. Also, personality-wise, certain people are more assertive in a discussion. In order for the estimation process to be meaningful and effective, it is important for all team members’ opinions to be taken into account.
Planning Poker is a voting process that insures that everyone’s opinion has equal value and that all concerns are taken into consideration. After all, certain members might have a better understanding or sensitivity to potential issues that could hide complexity. In planning poker, each Dev Team member has a card for each story being considered. On the card, the member will write their estimate of the story, using the Story Points (see the fibonacci sequence section under Estimation for more info). The members will then present their cards to the entire group. If anyone’s estimate is higher or lower than the prevailing estimate, those team members are given the chance to explain their thought process. Then, taking those new perspectives into consideration, everyone votes again, and the process repeats until there is unanimous consensus on how many Story Points are represented by a given Story.
Once the final set of stories are placed onto the Sprint Backlog, the Dev Team will break them down into tasks and otherwise determine how everything will get built, and by whom, by the end of the sprint.
The team will then be ready to start the sprint.