The Scrum approach to agile software development marks a dramatic departure from waterfall management. Scrum and other agile methods were inspired by its shortcomings. Scrum emphasizes collaboration, functioning software, team self management, and the flexibility to adapt to emerging business realities.

20th
AUG

Scrum Meetings

Posted by admin under Scrum Basics

Sprint Planning Meeting

In Scrum, every iteration begins with a sprint planning meeting. At this meeting, the Product Owner and the team negotiate which stories a team will tackle that sprint. This meeting is a time-boxed conversation between the Product Owner and the team. It’s up to the Product Owner to decide which stories are of the highest priority to the release and which will generate the highest business value, but the team has the power to push back and voice concerns or impediments.

When the team agrees to tackle the work, the Product Owner adds the corresponding stories into the sprint backlog. We usually recommend this be physically represented by moving a Post-It note or index card with a story written on it from the backlog into the sprint backlog.

At this point, the Product Owner may choose to leave while the team decomposes the forecasted backlog items into tasks. This meeting is sometimes called Sprint Planning Part 2.

In Large Scale Scrum, multiple teams pull items from one Product Backlog. Multiple backlogs for one product, and multiple Product Owners lead to localize suboptimizations, longer work-in-progress queues, thus are harmful to agility.

Watch an example Sprint Planning Meeting.

The Daily Standup

Every day, the Scrum team gathers in front of their taskboard to discuss the progress made yesterday, goals for today, and any impediments blocking their path.

  • What have I done since the last Scrum meeting (yesterday)?
  • What will I do before the next Scrum meeting (tomorrow)?
  • What prevents me from performing my work as well as possible?

This meeting should not exceed 15 minutes. If members of the team need to discuss an issue that cannot be covered in that amount of time, we recommend they attend a sidebar meeting following the standup. This allows team members to attend meetings that directly involve their work, instead of sitting through irrelevant meetings. Unfortunately, daily Scrums often last longer than 15 minutes. To compensate, many teams use stop watches or timers to uphold the time limitations. Also, to limit distracting small talk, many teams employ a talking stick or mascot, which a team member must hold to speak in the meeting. Upon finishing an update, the talking stick is then passed to the next team member, who reports, and so on.

http://www.open.collab.net/nonav/community/swp/training/DailyScrumMeeting/DailyScrumMeeting.htm” target=”_blank”>Watch an example Daily Scrum Meeting.

 

Sprint Review Meeting

When the sprint ends, it’s time for the team(s) to demonstrate a potentially shippable product increment to the Product Owner and other stakeholders. The Product Owner declares which items are truly done or not. Teams commonly discover that a story’s final touches often excise the most effort and time. Partially done work should not be called “done.”

This public demonstration replaces status meetings and reports, as those things do not aid transparency. Scrum emphasizes empirical observations such as working products.

In Large Scale Scrum, multiple teams demonstrate a single integrated product increment.

Watch an example Sprint Review Meeting

Sprint Retrospective Meeting

After the sprint review meeting, the team and the Scrum Master get together in private for the retrospective meeting. During this meeting, the team inspects and adapts their process. When the Scrum Master and outer organization create an environment of psychological safety, team members can speak frankly about what occurred during the Sprint and how they felt about it. After all team members thoroughly understand each other, they work to identify what they’d like to do differently the next Sprint, typically focusing only on one or two specific areas of improvement each Sprint. The Scrum Master may also observe common impediments that impact the team and then work to resolve them.

Overall Retrospective Meeting (Large Scale Scrum only)

In Large Scale Scrum, the Sprint Retrospective is followed by an overall retrospective that focuses on inter-team interactions and the outer organization.

Watch an example Sprint Retrospective Meeting.

 

Comments Feed

Reader's Comments

  1. Gayathri |

    All the videos are very good. Can you provide us a video on ‘Release Planning Meeting’?

  2. guter-webhoster.de |

    Thanks for the video, it explains it really easy how sprint planning works.
    It is totally important to have a good planing before focussing, because than it is easier to focus.

  3. admin |

    We run our teams, and we advise our customers, that the PO is not involved in retrospective meetings, simply because some of the issue raised in the retrospective may have come from that individual. I’ve heard it argued that since the PO is a member of the team, he should be involved in retrospectives.

  4. Rick Reagan |

    At the end, this article says “Since the Product Owner sits this meeting, team members can speak frankly …”

    I assume you meant to say “Since the Product Owner sits OUT this meeting…”

    I believe it depends on the PO relationship with the team. In our case, the PO has been working with most of the team members for 20+ years (unusual, I know) so it seems normal for the PO to be included in the retrospective.

  5. Jim |

    Hi I have 2 questions?

    In four weeks time, What happens when the committed task were not finished?
    Or there are bugs?

    Ho do we schedule a bug fix after the PO rejected the product?

  6. SheTech |

    In my experience with the retrospective, we had two end-of-scrum conversations: the sprint review included the Product Manager, and the retrospective excluded him/her. That way, we could review the iteration “officially” and help balance resources AND speak frankly about process improvements.

  7. Ruud |

    Having or not having the PO sit in on the retrospective depends on some factors. How much do you want/need to improve the relationship between the dev-team and the PO? How open is the PO for feedback? How smooth do you want your process to go?
    I think the PO is important to include in retrospectives; in that way the whole set of processes can be improved. It is however true that when the team gets too technical, the PO might be excused from the meeting.

Leave a Reply


CAPTCHA Image
Reload Image

Scrum Training Courses