Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ceremonies (meetings): #57

Open
chrisjun1 opened this issue May 10, 2019 · 0 comments
Open

Ceremonies (meetings): #57

chrisjun1 opened this issue May 10, 2019 · 0 comments

Comments

@chrisjun1
Copy link
Collaborator

chrisjun1 commented May 10, 2019

Standup

Attendees:
full internal team (designers, engineers, UX), scrum master, project manager

When:
daily or twice per week

Duration:
15-30 mins -- more time may be needed if the frequency of meeting has decreased

Purpose:
Stand-up is designed to quickly informing everyone of what is going on across the team.
Each team member should answer the following questions:
- What has been done since the last time the team met?
- What will I be working on next?
- Is there anything blocking me from doing what I need to do?

Note:
Daily standup encourages progress and clearing of blockers.

Sprint Planning

Purpose:
Sprint planning sets up the entire team for success throughout the sprint. Coming into the meeting, the product owner will have a prioritized product backlog. They discuss each item with the development team, and the group collectively estimates the effort involved. The development team will then make a sprint forecast outlining how much work the team can complete from the product backlog. That body of work then becomes the sprint backlog.

Attendees:
full internal team (designers, engineers, UX), scrum master, project manager, product owner

When:
before a sprint starts, usually the day before

Duration:
Usually, an hour per week of iteration–e.g. a two-week sprint kicks off with a two-hour planning meeting.

Backlog Refinement (internal and external)

Attendees:
Internal: project manager, development team
External: product owner, project manager, development team (optional)

When:
Internal: As much as needed to come to a consensus on stories for the next sprint at the minimum
External: Weekly

Duration:
Internal: 15-30 mins at a time
External: 1hr - 1.5 hrs

Purpose:
Backlog refinement is a time to do exactly what the name says, refine the backlog. Stories that are not currently being worked on but are next up to be put into a sprint need to be in a ready enough state to be taken into development. They should have the following pieces of information detailed out:

  • Story (As a ... I want ... so that ...)
  • Description
  • Acceptance Criteria
  • Links to design comps if needed
  • Notes if needed

Backlog refinement is traditionally done by the product owner with feedback taken in from the development team and stakeholders. This usually takes the form of 1 or more weekly meetings between all of the parties involved. Projects with shorter timeframes benefit when the overhead of meetings can be kept to a minimum. In order to do this and at the same time still collect the feedback from the everyone involved, it may benefit the project to split up the backlog sessions into an internal session and an external. The development team can provide feedback on stories at their own pace while the project manager and product owner discuss the backlog during a more traditional meeting cadence.

Sprint Review

Attendees:
development team, scrum master, product owner

When:
At the end of a sprint

Duration:
.5hr - 1 hr

Purpose:
Sprint review is a time to showcase the work of the team. This is the time for the team to celebrate their accomplishments, demonstrate work finished within the sprint and get immediate feedback from project stakeholders. Remember, work should be fully demonstrable and meet the team's quality bar to be considered complete and ready to showcase in the review. Not all project timelines will allow for this to happen but it is imperative for a team to celebrate work at some point in time even if it is after the launch.

Retrospective

Attendees:
development team, scrum master, product owner

When:
At the end of a sprint or project

Duration:
1hr

Purpose:
Retros help the team understand what worked well and what didn't during a given sprint or project. They aren't just a time for complaints without action. Use retros to find out what's working so the team can continue to focus on those areas. Also, find out what's not working and use the time to find creative solutions and develop an action plan. Continuous improvement is what sustains and drives development within an agile team, and retrospectives are a key part of that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant