Ceremonies (meetings):

[chrisjun1]

Backlog Refinement (internal and external)

Purpose:
Backlog refinement is a time to do exactly what the name says, refine the backlog. Stories (tickets) 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 internal 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. It is the responsibility of the project manager to gather the priorities from the client (product owner) and communicate those back to the internal team.

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

Sprint Planning

Purpose:
Sprint planning sets up the entire team for success throughout the sprint. Coming into the meeting, the project manager in partnership with client (product owner) will have a prioritized product backlog. The project manager will pull each story (ticket) up, discuss the detail of the ticket in full, the group collectively estimates the effort involved. The 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, client (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.

Standup

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

When:
Once per day, typically in the morning.

Duration:
~15 mins and try actually standing instead of sitting

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 did I do yesterday?
- What will I do today?
- Is there anything blocking me from doing what I need to do?

Note:
Daily standup encourages progress and clearing of blockers.

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.