MXA TEAMS: Agile Cadence Refresh

1. MXA TEAMS: Agile Cadence Refresh • December 5, 2012 1

2. CISCO MXA TEAM CADENCE 2

3. | sprint cadence Release Planning 3 Amigos Daily Standup Sprint Review Backlog Grooming Retrospective Scrum of Scrums Sprint Planning 3

4. STEP BY STEP 4

5. 1 | release planning • HOW • Gather team members in large space or around large table. • Review Product Backlog. Product Owner reads feature description and acceptance criteria, then answers any questions. • 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. • 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. • 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 5

6. 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. | sprint planning 6

7. HOW • 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. 3 | daily standup l;akdsfk;ldkasf 7

8. | 4 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 l;akdsfk;ldkasf 8

9. 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. 5 | 3 amigos NEW! l;akdsfk;ldkasf 9

10. 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). 6 | backlog grooming NEW! l;akdsfk;ldkasf 10

11. 7 • HOW • 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. | sprint review l;akdsfk;ldkasf 12

12. 7 • 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 13

13. 8 • 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 l;akdsfk;ldkasf 14

14. S S D W S W D S A S A A | cadence when Each Day Each Week Each Sprint Anytime Release Planning Sprint Review 3 Amigos Daily Standup Retrospective Backlog Grooming Sprint Planning Scrum of Scrums 15

15. OBSERVATIONS 16

16. A | release planning Release Planning • 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. 17

17. S | sprint planning • 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 18

18. D | daily standup Daily Standup • 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. 19

19. W | scrum of scrums • 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. Scrum of Scrums 20

20. A | 3 amigos NEW! 3 Amigos • 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. 21

21. S | backlog grooming NEW! • 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 22

22. S | sprint review • 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. Sprint Review 24

23. S | demo Demo • 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

24. S | 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 26

25. | sprint cadence Release Planning 3 Amigos Daily Standup Sprint Review Backlog Grooming Retrospective Scrum of Scrums Sprint Planning 28

26. | • HOW • 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. forecasting capacity/velocity 29

27. S S D W S W D S A S A A | cadence when Each Day Each Week Each Sprint Anytime Release Planning Sprint Review 3 Amigos Daily Standup Retrospective Backlog Grooming Sprint Planning Scrum of Scrums 30