At the beginning of each sprint, a sprint planning meeting must be conducted to determine which Product Backlog items will be completed during the sprint and create the corresponding sub-tasks.

Sprint Planning Input:

1. Top prioritized Stories from Product Backlog are groomed and meets the Definition of Ready.
2. All Team members are present (in person or over Webex), unless otherwise communicated to the Scrum Master.
3. Team members should know their own individual capacity for the team prior to Sprint Planning.
4. Scrum Master displays the JIRA Product Backlog on the WebEx/Projector

The Sprint Planning ceremony should follow the following guidelines:

1. For a 2 week Sprint, anticipate up to 4 hours for Sprint Planning. Depending on how successful the backlog grooming sessions were will determine how much time you and your team spends in Sprint Planning.
2. The Scrum Master will perform a capacity analysis by asking the team who will be on PTO, training, etc. and looking at the previous average velocity. The formula is to give each person 8 points per sprint and then subtract 1 point for each day they are not available. A day is further defined as 8 hours. Sprint boundaries are firm. 2 weeks is 2 weeks and capacity analysis is based on the fixed timebox.
3. Product Owner should be present for the Sprint Planning ceremony with prioritized backlog of Stories. This requires that all User Stories are groomed with Title, Narrative, Description, Acceptance Criteria, and other supporting information as needed.
4. Product Owner will discuss the sprint goals they would like to accomplish during the sprint and present the prioritized Stories to the team, one at a time, from the top of the backlog. If the story is technical, a spike, or defect, it should be read by someone from the Team. 
5. Team may ask questions to get clarification on Stories. Details of the story may be updated at this time. Further details of Stories and Sub-Tasks can be discussed during the Sprint, as long as the Team feels confident the Stories will be completed within the Sprint.
6. If estimation was not done in Backlog Grooming, then the Team estimates the backlog item using the Fibonacci Scale (0, 1, 2, 3, 5, 8, 13, 21, 34, 55…). The Story estimations are based on complexity. Complexity is defined as effort, risks, and unknowns, and is relative to other Backlog items. Therefore, each team should have a baseline story as 1 point, 1 day. This means a Story can be completed by one “ideal” person in 1 day. When the Team does relative sizing, they are comparing the Story size to the baseline Story. For a Story committed to a Sprint, the Story size should be 8 points or less.
7. If there is support work that the team will do in the Sprint but it is not known at the time of Sprint Planning, the team can put a Support work item as a Technical Story into their Sprint Commitment and estimate it in points. For example, if the team has a velocity of 40 points and they predict roughly 1/5th of their Sprint will be support work, they can give 8 points for the Support Story and add the tasks once the work is defined in detail.
8. if there is no support work raised in the current sprint then the team can take equivalent Story points from the backlog.
9. Sprint commitment will be based on the team’s confidence and velocity. The Scrum Master should facilitate the team discussion for committing.
10. For remote team members, it is important the Scrum Master has access to a screen sharing service, such as, WebEx to share their screen with the team. If possible, tele-presence is highly recommended. For example, if team members are in Europe and the U.S. – having a tele-presence between Europe and the U.S. helps to unite the team and make them feel more like one team. This also is helpful when doing point estimation.
11. Once the team initially commits to the Sprint Backlog, the team will break down the Sprint Backlog Items into sub-tasks. Each sub-task should be between 2 to 16 hours and have an assignee (the person that will be doing the work). The estimated hours need to be inputted into the estimate field for that sub-task in JIRA.

• If a Story or Sub-Task is dependent on another Team’s backlog, that Story should be linked to their Story as dependency in JIRA and the Scrum Master should help ensure the dependency does not become a blocker.
• The Team can use the Sub-Task Breakdown to reconfirm the Sprint Goal(s), verify individual capacity, validate Story estimates, and Sprint commitment.
• Please Note: Sub Tasks do not directly correlate to Story Points because points represent complexity. Complexity has 3 parts: Effort, Risks, Unknows, Sub Tasks only represent Effort.
• Please Note: the assumption is that a full time, dedicated person would have 64 hours of capacity in a 2 week Sprint.

A prefix of [Dev], [Services], [Framework], [Test], etc. should be placed in front of the sub-task name.

Sprint Planning output:

• Sprint Commitment based on Team’s velocity.
• Sub-task breakdown for all Stories.
• Sprint Goals identified and agreed to.
• Sprint started in JIRA.

Impediments that are blocking team members from completing their sub-tasks should be put through an obstacle removal process. The obstacle removal process would follow the below process:

1. The Scrum Master should create and track the blocking issue on a virtual or physical team level Kanban (resolution) board.
2. After 24 hours (business day), if the blocking issue is not resolved, then the blocking issue should escalate to an immediate technical/business leader.
3. After another 24 hours (business day), if the blocking issue is not resolved, then the blocking issue should escalate to the appropriate manager.
4. After another 24 hours (business day), if the blocking issue is not resolved, then the blocking issue should escalate to leadership.

Attendees: Product Owner, Scrum Master, Team, Invited Stakeholders.

The Review ceremony will be held to formally accept Stories from the Sprint. The Product Owner accepts the Stories, the Scrum Master facilitates, and the Team demos the work completed in the Sprint. This ceremony should be timeboxed between 1 to 2 hours depending on all the stakeholders attending and the scope of the demo. The Sprint Review should follow the below guidelines:

Input:

Sprint Summary Report.

1. Scrum Master should give a high-level summary of the Sprint’s goals, velocity, and what the Team committed and delivered. For work items not delivered, an explanation should be provided. Scrum Master should only spend 5 to 7 minutes on this.
2. Product Owner must be present to review the Stories, and confirm that all acceptance criteria have been met. As each Story item is presented by the Team, the Product Owner should accept or not accept the Story based on the Definition of Done, which including the Acceptance Criteria.
3. Product Owner should only accept Stories that fully meet the Definition of Done. Stories that don’t meet the full Acceptance Criteria should be not be accepted unless the pending work is cosmetic or considered minor – in which a negotiation between the Team and PO will occur.
4. Stakeholders may also be invited to the Sprint Review to view the completed Stories.
5. The Team gives a demo and overview of the Stories completed in the Sprint.
6. Team members should demo their work to the Product Owner and any present stakeholders. However, stakeholders should refrain from asking questions until the demo is completed.
7. Stakeholders should provide feedback as necessary.  Feedback will be filtered and prioritized into the Product Backlog by the Product Owner. Product Owner is responsible for collecting the feedback. However, the Scrum Master can also assist as needed.

Output:

1. Story Acceptance.
2. Product Owner & Stakeholder Feedback.
3. Updated Release/Version Report (automated in JIRA).

Note: If the PO can accept Stories in real time, that would be preferred and the Scrum Master will schedule the Review with the PO and Team member(s) that worked on the Story.
Note: Demos should be showcased on the QA or Staging environment from an integrated build.