110 likes | 210 Views
<<insert customer logo>>. API Release: Date: Presented by:. Sprint Planning Presentation. Purpose. <<DELETE THIS SLIDE BEFORE SHARING PRESENTATION WITH CUSTOMER> >
E N D
<<insert customer logo>> • API Release: • Date: • Presented by: Sprint Planning Presentation
Purpose <<DELETE THIS SLIDE BEFORE SHARING PRESENTATION WITH CUSTOMER>> • This presentation should be used as a tool in the sprint planning meeting to review and obtain agreement on what will be accomplished by the team during the upcoming sprint. • The goal is to have team members involved with decisions by interactively reviewing the backlog and discussing which user stories will be included in the upcoming sprint. • The expected outcome of the backlog review is a sprint board with approved user stories that areready to start on the agreed upon date. In order to accomplish this outcome, Apigee’sScrum Master will need to drive the backlog review by using an online meeting tool to show the current backlog and the active build of the upcoming sprint board based on the team’s discussion and feedback.
Sprint Information Customer Details Apigee Details • API Domains: • Consumer/Internal Project Name: • Sprint Overview: Include information such as theme of sprint, timeframe for sprint, internal deadlines driving sprint completion, etc • Team Members: • Project Manager • Development Lead • Technical Architect(s) • Test team • Team Members: • Scrum Master • Development Lead • Technical Architect(s) • Test team • Retrospective Review: • Discuss top 3 retrospective items from previous sprint retrospective reviews to incorporate lessons learned into upcoming sprint • Retrospective item 1: • Retrospective item 2: • Retrospective item 3: • Provide review of overall program progress and highlight items to focus on given the team’s current progress [i.e. required information for JIRA ticket before developer passes to test team, process to manage defects to resolution, etc.]
Sprint Planning Agenda • Backlog review to determine user stories in scope for upcoming sprint • Refer to active JIRA sprint board for review • Build upcoming sprint board during review • Assumptions and Constraints • Timeline • Team member capacity review • Risks • Communication Plan • Questions
Backlog Review At this point in the sprint planning meeting, Apigee’s scrum master will lead the backlog review directly in JIRA. The outcome will be a final list agreed upon by the team that includes all user stories, tasks, sub-tasks, QA tasks, feature requests, improvement requests, new features, and bugs that will be addressed during the upcoming sprint. <<screenshot shown for reference only – delete before sharing presentation with customer>>
Assumptions & Constraints Assumptions List all assumptions that apply to the upcoming sprint: [SAMPLE 1]: backlog includes all currently known and identified technical requirements Constraints List all constraints that apply to the upcoming sprint: [SAMPLE 1]: sprint must be completed prior to internal customer deadline of June 1
Timeline Notes & Team Capacity Notes • Address any notes applicable to the published timeline for the upcoming sprint: (examples below) • Peer review to occur prior to deploying to Dev • QA deploy to occur daily for completed tickets • Code lock to occur on 9/9 • Review of open tickets (if any) to occur on 9/9 prior to deployment to Stage: • Finish in sprint • Defer to next sprint • Proceed with known defects in sprint • Stage deploy will occur AM/Noon Monday • Review of open tickets and issues to occur on Wed of GNG, similar decision criteria as noted above. Team member capacity confirmation • Team member capacity and impact to upcoming sprint: • Team member 1 – PTO March 20-25 (no impact) • Team member 2 – PTO May 1-8 (shift open tickets to other available team member) • Confirm capacity • List any changes to capacity
Communication Plan • Kick-off meeting • Daily scrum meetings • Peer reviews daily prior to each deployment • Grooming of sprint content (weekly meetings with Project manager and Scrum master) • Dev planning sessions bi-weekly (ticket break downs/estimate quality) • Evaluation on Mondays of devcompletion if any items are not complete: • Finish in sprint • Defer to next sprint • Proceed with known defects in sprint • Retrospective after sprint completion
Questions Questions?