| 5 release planning HOW 1.Gather team members in large space or around large table. 2.Review Product Backlog. Product Owner reads feature description and acceptance criteria, then answers any questions. 3.Write the name of each feature on a separate Post-it and display on a large whiteboard or series of poster-sized Post-it charts. Use a Sharpie and write the feature name in large letters so attendees can see from a distance. 4.With Product Owner, prioritize all the features. Priority should be listed top to bottom, left to right. 5. Estimate each feature, using T-shirt size. Write the size on each feature Post-it. 6. Review the T-shirt sizes of the top ten features. Depending on how many teams will be working the features and their average velocity, you should be able to quickly estimate how many features the teams can build per month or per quarter. 7. Determine which features need to be built within the next release period (month? quarter?). 8. For each of these high-priority features, write all of its epic titles (using Sharpies) on Post-its. Again, one epic title per Post-it. DIsplay next to or beneath each feature name. 9. Estimate each epic of each feature, again, using T-shirt sizes. Write each epic's size on the epic Post-it. Does the epic total equal feature's T-shirt size? If not, adjust as needed. 10. Calculate or list (if you already know it) team's average velocity. 11. Slot epics/features into sprints based on priority and average velocity. Reorder as needed. 1 WHAT Collaborative planning session to determine which features, epics, and/or stories should be included in a product release. NOTE: Scrum Guide has no Release Planning event. WHEN On a regularly scheduled day/time or as needed...but at least once during the amount of time of a release (e.g., if you release code once a month, run this meeting once a month). Schedule at least two hours WHY Get a look at the big picture of what we're building and when we can release it Reorder or reprioritize based on changes in the business WHO All Core team members, including Product Owner, (required) Extended team members (recommended) Others (by invitation) MXA T-SHIRT SIZE KEY XS = 1 week S = 2 weeks (1 sprint) M = 1 month (2 sprints) L = 2 months (4 sprints) XL = 3 months or more
| 6 WHAT Regular planning session where team decides which user stories it will work in the upcoming sprint By first calculating capacity of each tam member, the team forecasts how many story points it can complete it he next sprint, WHEN Team decides when to do sprint planning. Generally, it is either the last day of the current sprint or on the morning of Day 1 of the new sprint. Best done after Release Planning. WHY Commit to working and completing stories in order to deliver predictably and reliably. Deliver the business value and priority determined. By the Product Owner. Empower the team to make its own decisions. WHO All core team members Product Owner must attend Scrum Master generally schedules and leads sprint planning 2 HOW 1. Team members gather. 2. Scrum Master leads team in calculating and forecasting velocity for the new sprint. 3. Product Owner discusses the goal of this upcoming sprint in terms of which stories he/she would like the team to consider bringing into the Sprint Backlog. EXAMPLE An example of a sprint goal: "In Sprint 1, our team goal was to build all remaining user stories related to the Add Funding Account feature." 4. Product PO reads each intended user story and its acceptance criteria. If necessary, PO also reads story's epic and feature writeup. 5. Team discusses each story, one at a time. After the team's questions have been answered and all agree this story can get to Done by the end of the sprint, the story is estimated in story points, then moved into the Sprint Backlog. 6. Team tasks each story. Tasks should be three hours or fewer,and estimated hours written on each task. 7. Scrum Master places new stories in the Story queue of the storyboard. 8. Scrum Master writes new velocity forecast in big numbers on Post-it and places at the top left of the storyboard.
l;akdsfk;ldkasf | 7 WHAT Daily, 15-minute team gathering. Team members provide and receive information from each other. This information helps keep the team on track and exposes issues to be solved. WHEN Monday through Friday Same time each day 15 minutes Start and end on time Do not allow team members to be late WHY Have at least one time per day when team is together. Team members provide updates about their work. Team members express any roadblocks impeding progress so Scrum Master can clear them. WHO All core team members For all core team members, Daily Standup is mandatory. Schedule your other meetings around it. Visitors welcome but may not always speak. They stand outside the circle. HOW 1.Team gathers at storyboard. 2. Scrum Master either goes first or encourages a team member to start. 3. Each team member answers these three questions: * What did I do yesterday? * What will I do today? * Do I have any roadblocks/impediments? 4. Scrum Master notes, and tracks, any roadblocks/impediments; then, updates the team about progress of resolving them. 5. Any extra conversation (not related to the 3 questions) is taken offline. Any team member can encourage a discussion to be taken offline. 6. Each team member updates the status of his/her story cards or tasks by moving them into the proper queues on the storyboard. 7. Scrum Master escalates any roadblocks/impediments as necessary during the Scrum of Scrums. daily standup 3
l;akdsfk;ldkasf | 8 WHAT 15-minute team gathering. Leaders gather in open space on 2 Each provides updates, information, and issues the others need to know. WHEN Tuesdays + Thursdays 12:00 to 12:15 Start and end on time WHY Hear what the other teams are working on and determine if any of their activities apply to or affect any work your team is doing. Great way to hear of dependencies Tackle potential roadblocks early WHO Key leaders, including Product Owners, Scrum Masters, Art, Kui, Jen, Kramer Visitors welcome but do not speak unless necessary. Visitors stand outside the circle. HOW 1. Leaders gather in a circle in open space on 2 for now, but will meet at the DAW (Delivery Alignment Wall) when it's available. 2. Each participant answers the three questions of Daily Standup, but is not limited to this. 3. Each also shares information/updates/roadblocks the others need to know. 4. If any decisions are needed, the group makes them and communicates them to the right team members, other leaders, or executives. 5. Leaders update Leadership Backlog BVC (Big Visible Chart) as needed. 6. After Scrum of Scrums, leaders take appropriate action, which may include dealing with any impediments/roadblocks escalated from the teams' Daily Standups. scrum of scrums 4
l;akdsfk;ldkasf | 9 WHAT A way to gather key team members and estimate work on the fly Or, a way to re-estimate when anyone in the team believes a better estimate is warranted WHEN Anytime before or after Sprint Planning that a user story or other work needs to be estimated WHY Estimate user stories or other Product Backlog Items accurately via reps from the key areas of Business and IT A way to estimate anytime, not just in Sprint Planning Quick response to change WHO Balance of representatives from the Business, Development, and IT: Product Owner, Developer, and Tester, or UX, Architect, and Tester Others may attend (often, Scrum Master likes to be there) HOW 1. Team member calls a 3 Amigos. Team decides who the 3 should be. 2. The 3 Amigos gather, either in the open team space, in their team space, or in a meeting room. 3. Although the Product Owner (or his/her proxy) typically reads the use story and provides and relevant information about it, any of the Amigos can do this. 4. The 3 Amigos ask questions to clarify their understanding of the story. 5. When ready, someone calls a vote. The 3 Amigos hold up fingers to indicate the number of story points needed to complete the story. 6. If all agree on the point size, great. Otherwise, Amigos discuss and revote until all agree on point size. 7. Someone writes the story point number on the story card. 8. The 3 Amigos may opt to task the story now or later. 9. The 3 Amigos disband. 3 amigos 5 NEW!
l;akdsfk;ldkasf | 10 WHAT A team view of the work nt the Product Backlog and a way to address changing. Business or IT priorities. A timeboxed activity that helps team(s) keep focus on what's most important. WHEN Second Wednesday of the sprint Timeboxed at one hour Typically, same day/time each sprint, but this is optional...do what makes sense, as long as it happens one time per sprint WHY Pinpoint, then discuss Product Backlog work regularly. *This is especially valuable for multiple teams working the same Product Backlog. Reorganize and visualize changes in priority. WHO Bare minimum, Product Owner, Scrum Master, Dev Lead or Architect), and QA Lead from all teams Others may attend; group decides who HOW 1. Group gathers at the Product Backlog. 2. Together, review items in the Product Backlog ( feature, epics, stories, ideas, etc.). Remember that the priority of all product Backlog items should be listed as: Top to bottom Left to right 3. Reorder items as needed to reflect changing priorities. 4. Discuss next steps for getting to Done. 5..Commit to sense of urgency for deadlines. 6. Capture, post, and escalate roadblocks (risks/issues/blockers). backlog grooming 6 NEW!
l;akdsfk;ldkasf | 11 WHAT Review and validate that a newly built user story *meets the acceptance criteria, *works as designed Code passes architectural review. WHEN Anytime a story has been built and the 3 Amigos (Product Owner, Developer, and Tester) want validation the story is Done and that the Architect approves the code. WHY Built-in accountability that had team has built and delivered a user story that meets the Product Owner's acceptance criteria. WHO Typically, the original 3 Amigos plus Governance If one of the original 3 Amigos is not available, a proxy is permitted as long as he/she will take responsibility for functional/unit testing the story's code. HOW 1. When story is but and ready for review, someone calls a 4 Amigos. 2. The 4 Amigos gather. Often, this occurs at the machine of the developer who built the story. But, it can occur anywhere the team can see the code and the working story (functionality). 3. The Product Owner reads the original user story and the acceptance criteria. 4. The developer shows the story. 5. The Amigos validate that what's been built meets the acceptance criteria. 6. The Product Owner gives approval. 7. The Architect performs a code review and confirms all unit tests have passed. 8. The Architect approves the story's technical quality. 9. The Product Owner approves the story's business value. 10. The 4 Amigos mark the story as Done and disband. 4 amigos 7 NEW!
l;akdsfk;ldkasf | 12 WHAT Review/discuss how things went (also done during Retrospective) Demo story progress to stakeholders and Product Owner NOTE: According to Scrum Guide, Demo is part of Sprint Review. But I've included it as a separate activity in our cadence. See next slide. Get approval on Done work Calculate velocity WHEN Day 10 of sprint: 2 hours NOTE: This includes Demo. Sprint Review activities on this slide should be 30 minutes tops...use the rest of the time for the Demo. Can be on another day if stakeholders unavailable, but as an exception, not the rule. Scrum Master needs to schedule in advance and confirm stakeholders will attend WHY Close out the old sprint before opening the new one Discuss progress and demo completed stories to Product Owner and key stakeholders WHO All Pismo Core team members, including Product Owners (required) Extended team members or guests (by invitation) sprint review 7 HOW 1.Scrum Master gathers team. This typically includes Core/Extended team, plus any stakeholders/customers who need to be present for the Demo. 2. Scrum Master states purpose is to demo work of this past sprint, which opened on [say date] and will close today [say date]. 3. Development team discusses these topics: Work from this sprint (which is ending) that is Done/Not Done Velocity achieved during this sprint Challenges, issues, and problems and how team solved them. 4. Development Team demos stories built in this past sprint. NOTE: See Demo slide. 5. Development Team asks Product Owner (or stakeholders) if story meets acceptance criteria. Yes? Then story is Done. 6. Product Owner discusses Product Backlog and gives a projection about delivery date based on where things stand as a result of this sprint's achievements. 7. Scrum Master calculates and records velocity achieved during this past sprint. 8. Scrum Master communicates sprint velocity to team and if any stories did not get to Done, team discusses. 9. Scrum Master removes Done stories from storyboard/story wall and moves any uncompleted stories into different queues as needed.
| 13 WHAT Bring Product Owner, Devleopment Team, and stakeholders/customers together to see the work that was done in the previous sprint (which is ending today). Read through the stories and AC, then show code or functionality. WHEN Is technically part of Sprint Review. Generally, last day of sprint. Can be on another day, but not ideal. Scrum Master should schedule several in advance. WHY Demonstrate progress to stakeholders and/or customers and/or execs. Prove that the team built what the Product Owner and customer have requested/required. Celebrate progress and teamwork! WHO All Pismo Core team members, including Product Owners (required) Satish Stakeholders, customers, executives...anyone who cares about what your team delivers HOW 1. On day of Demo, Scrum Master gathers team and ensures seating for stakeholders/guests. 2. Tech Lead/Devs open all necessary files in advance and run through them in order to finalize and verify the Demo agenda. 4. Scrum Master opens Demo session by welcoming all, making introduction of all team members, and walking through agenda (which is the list of user stories that will be shown). 5. Product Owner shares the goal of the previous sprint and the general results of what the team has delivered. 6. Product Owner reads each story and designated team member (typically, developer) displays the corresponding code functionality on the screen and walks through it for the attendees. 7. Product Owner and stakeholders validate that the work done matches the story acceptance criteria (e.g., requirements) and either approve each story or indicate bugs/shortcomings. 8. Scrum Master notes all changes/requests/approvals and discusses with Product Owner after Demo has ended. 9. Scrum Master formally asks Product Owner for approval of sprint's work. Either story by story, or at the end when all stories have been demonstrated. 10. Scrum Master or PO thanks stakeholders for attending, ends Demo session, and follows up as needed. demo 7
l;akdsfk;ldkasf | 14 WHAT Time together as a team to inspect, reflect, and adapt Discuss what worked well and what didn't in past sprint Also, review Not Working Wells from last sprint and show how team improved them WHEN Last day of sprint (Day 10) Typically, after Demo WHY Together, as a team, reflect on the past sprint Determine what/how to improve Celebrate what worked well and make changes in what didn't WHO All core team members of your team Does not include stakeholders or management or executives Sometimes, does not include Product Owner...it's up to the team HOW 1. Scrum Master gathers Core team. 2. Scrum Master either writes on a whiteboard or creates two BVCs, titled: Working Well Not Working Well 3. Scrum Master opens Retrospective and reminds team of purpose and goal (which is to take time at the end of each sprint/iteration to reflect, share feedback, and improve 4. Scrum Master gathers input for Working Well and Not Working Well. This can be done in several ways: Populated Working Well/Not Working Well where team members write their comments and post them on the designated areas of a whiteboard or on a BVC. Roundtable Working Well/Not Working Well where Scrum Master asks each team member to state his/her insights verbally. Scrum Master writes the comments on Post-its and displays on whiteboard or BVC. 5. Team discusses and chooses top 2 or 3 Not Working Wells to improve by end of next sprint. 6. Scrum Master displays Retrospective BVCs in team space and follows up to resolve Not Working Wells. retrospective 8
15 | whencadence Release Planning Sprint Planning Daily Standup Scrum of Scrums 3 Amigos Backlog Grooming Sprint Review Retrospective D W A S A SSS D Each Day W Each Week S Each Sprint Anytime A
| 17 planning Release Planning release Release Planning is not an official Scrum event. But, doesn't matter...we need a way to get a rough-cut look at the future of our product delivery. For Pismo or other Agile models where multiple teams work from one Product Backlog, do Release Planning together. A
| 18 planningsprint Be sure to forecast your team velocity for this new sprint. After your team has estimated and tasked each story, consider slotting them in priority order: top to bottom; left to right. Add a Sprint Goal to your Storyboard. Sprint Planning S
| 19 standup Daily Standup daily Start on time. End on time. 15 minutes. That's it. Do Daily Standup every day, M-F. This is a mandatory Agile event...you need to be there. No excuses. Look at each other, not just Scrum Master. Take all other conversation offline. D
| 20 scrumsscrum of Leaders: We need to take this more seriously. We should build and work our own Backlog. This is not just to answer the same 3 questions the teams do during their Daily Standups: Escalate any issues during this session. Keep others updated on your team's progress. Determine what other conversations and/or collaboration are needed; then, meet up. W Scrum of Scrums
| 21 amigos 3 Amigos 3 Call a 3 Amigos anytime you need to collaborate and estimate a story or other PBI (Product Backlog Item). Talk through through the story, ask questions, confirm AC (Acceptance Criteria). Then estimate in story points. A NEW!
| 22 groomingbacklog Do this at least once per sprint. Only for one hour (at the most). Confirm the order (priority) of our work. Helps prep for the stories you'll bring into the next sprint. Backlog Grooming S NEW!
| 23 amigos4 Get an Governance or Dev Lead to do a code review and sign off. Not required, but usually invite the same team members as were in the 3 Amigos. The 4 Amigos is actually often 5 or 6 or even 7...you decide. A 4 Amigos NEW!
Scrum Master needs to state that we are closing out this sprint, which began on [date] and is ending today. A lot happens in Sprint Review...close out the old, confirm velocity, and Demo. Although Scrum Guide lumps Demo in with Sprint Review, we treat Demo as its own event. | 24 reviewsprint Sprint Review S
Take Demo seriously...this is a big deal for your team. Get stakeholders on the calendar for Demo a couple of months in advance. Put together an agenda in advance Have all files open before Demo begins; confirm everything works. Script it. Know who's showing what and when. Food is good. | 25 demo Demo S
| 26 retrospective Start new Retro by reporting on progress of the Not Working Wells from last sprint. Make sure you get feedback from all team members. Tackle the top 2 or 3 Not Working Wells and resolve them in the new sprint. Retrospective S
| 29 HOW 1.Determine how many team members will actively be working stories in this upcoming sprint/iteration. 2. Calculate capacity. Using a calculation of one story point = one day of work for a developer pair or a single team member, total the number of days in the iteration/sprint and multiply by team members who will actively be working stories. Use a calendar to review with the team any holidays, big meetings, team vacation days, etc., and subtract them from the capacity number. Example: if there are 10 days in the sprint/iteration and you have 5 developers/testers, you will have a capacity forecast of 50 points ( 3. Calculate the percentage each team member or pair is available to work the stories in the new sprint. You hope to have 100% dedicated team members, but some team members may be 75%, 50%, etc. 4. Adjust the capacity figure if necessary, to reflect the right percentage of capacity for each team member who will actively be working stories. Example: If two of the five team members from the above example are only available 50%, each can only complete five story points in a two-week iteration, not ten. So your team velocity forecast will be 40 story points, not 50. 5. Use this velocity forecast as the number of story points you will slot for the new sprint/iteration. 6. Write the velocity forecast number on a 3x3 or 4x6 Post-it so that it's large and easy to see. Include the sprint number and dates. 7. When the new sprint/iteration opens, display the velocity forecast Post-it somewhere on the team storyboard. capacity/velocity WHAT Rough-cut calculation to determine how much work a team can take on in a sprint Based on number of team members working stories and the percentage of their allocation/availability WHEN During Sprint Planning But, can be done anytime the Scrum Master or Product Owner want to get an idea of potential capacity for a given sprint Hint: Bring a calendar WHY Get visibility and clarity around how many story points a team can reasonably take and deliver during a sprint Forecasting, then tracking, velocity gives teams--and execs/stakeholders-- greater confidence in delivery timelines WHO Scrum Master with all Core team members For IT projects, developers and often, testers. Does not include Product Owner or Scrum Master stories/tasks. For nonIT projects, anyone actively working a story. forecasting
30 | whencadence Release Planning Sprint Planning Daily Standup Scrum of Scrums 3 Amigos Backlog Grooming Sprint Review Retrospective D W A S A SSS D Each Day W Each Week S Each Sprint Anytime A
Your consent to our cookies if you continue to use this website.