• EnglishEspañol日本語한국어Português
  • ログイン今すぐ開始

Meetings and ceremonies

Monday

Tuesday

Wednesday

Thursday

Friday

Sprint planning

Team meeting

Sprint review

Meeting-free day

We break our work into one-week sprints.

The new sprint starts on a Monday with sprint planning, where we commit to a set of stories that we're confident we can complete by the end of the sprint. On Thursday, we meet with stakeholders to get feedback on our deliverables for this sprint, and our plan for next. Then, managers and writers write new tickets for the next sprint, and a new cycle kicks off.

Sprint planning

Each Monday of a new sprint, we commit to a series of stories until we have filled our capacity for the sprint. Before the sprint planning meeting, the scrum master for each squad calculates their point budget.

Meeting rules

  • Silent estimation: At this point every story included in the sprint is well groomed and has been reviewed during grooming by all members of the squad. The entire squad reads each story silently. When all members of the squad have finished voting begins.
  • Blackout voting: In order to reduce influence, we blackout the cells in the spreadsheet until after a vote has happened. We change the background color to white to reveal the votes simultaneously.

Then, during the meeting:

  1. We select the highest priority story in the backlog.
  2. Everyone reads the story
  3. The team plays planning poker. Everyone secretly votes based on the modified Fibonacci sequence. (For more info, see Planning poker and points budgets.)
  4. Once everyone has voted, the scrum leader reveals the hidden votes.
  • If everyone votes the same, that's the point value and we move on.
  • If it's mixed, the highest and lowest voters briefly explain their votes. Then we vote again.
  1. Once we're sure we can fit the story in, we add the final vote to the "final" column. The points are then subtracted automatically from the total sprint budget.
  2. We repeat the above steps until we've used up our points budget.

Writing great tickets

Well groomed tickets serve two purposes. First, writing a truly excellent story requires that you have a strong understanding of the scope of work and how this story will ultimately impact the user. The end user should always be first in our mind when we plan our work! Creating clear action items for every story means that before you've started any work you've already spoken to subject matter experts and stakeholders so you're already ahead of the game!

Secondly, all tickets should be groomed and ready on the Friday before sprint planning. This is because the goal is for all members of the squad to converge on the same estimation for each story which requires everyone to have a clear understanding of the scope of work. This means that not only do we need good stories but we also need time and space to discuss these stories before sprint planning.

The moral of the story: If we understand our own stories, then we can better explain them to our squad.

ヒント

For an in-depth discussion of writing great tickets, see Ticket best practices.

Team meeting

Our weekly team meeting is the time we bring all the writers together across squads to discuss shared issues. While managers bring many topics, the agenda is open to anyone on the team and everyone agrees team meeting is at its best when there's lots of open discussion.

A good team meeting topic, then, has room for discussion. If your topic is just an FYI (this thing got published, this style guide doc changed), consider just posting a Slack PSA instead. Instead, look for topics that invite debate and conversation.

Sprint review

Each Thursday, the squad meets with key stakeholders to review:

  • Key metrics
  • What we did this sprint
  • And our plans for next sprint

The manager for each squad is responsible for planning a light agenda for the sprint review and leading the meeting.

Retrospectives

Ocasionally, we conduct a 60 minute retrospective meeting, where we discuss:

  • How do we feel about our process?
  • What went well?
  • Where can we improve?
  • Anything we should start or stop doing?

The goal of the retro is to improve the way we work together. That could be related to the sprint process, to how we collaborate with SMEs, to peer edits, and so on.

← Agile roles
Copyright © 2024 New Relic株式会社。

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.