Guideline for retrospective & sprint planning

Guideline for Retrospective & Sprint Planning Arata Fujimura

Scrum pillars, again • Keep the 3 pillars in your mind at least though there are so many rules about scrum. • Inspection • Adaptation • Transparency

Retrospective • Most IMPORTANT ceremony(event). • Inspect your process. • Create a plan for improvement. • Continuous improvement.

Retrospective • Discussion about TEAM issues, rather than personal issues. • Process • Practice • Collaboration • Working Environment • Tool

Retrospective • KPT2(Keep[good], Problem, Try, Todo) • One of the Retrospective methods http://agilenewsflash.blogspot.com/2012/02/kpt.html

Retrospective • Typical transfer of items between fields • Keep -> Definition of “Done" • Problem -> Impediment list • Try -> Todo • • Pick up next action. Todo -> PBI(Product Backlog Item)

Retrospective 1. Check previous KPT. 1. Check all items(post-it) on the Todo area(because there might be any items which were put last retrospective). 1. If there is any item which has a good effect for previous sprint, it move onto the Keep area. 2. If the item doesn't have any good effect for previous sprint, you remove it from KPT. 3. If you want to consider more about the item, you can keep it on the Todo area. 4. continue until checking on the Todo area completes

Retrospective 1. Check previous KPT. 2. Check all items(post-it) on the Problem area. 1. If there is any item which can/want to solve, it remains. 2. If you can't do anything to solve the item, you remove it from KPT. 3. Check all items(post-it) on the Keep area. 1. If there is any item which is already enough to share, no need to emphasize any more, you remove it from the Keep area. 2. You remove "good" stuff, too. 3. If the item must be still there as "KEEP", it remains.

Retrospective 2. Check the current status. 1. Write "Keep" stuffs that we had better to continue. You can write "Good" stuff, like a "Released" too. Write one stuff per one post-it. Keep quiet while writing and Write within 3 minutes. 2. Put the post-it on the Keep area, then read it for all members. It goes one by one until it completes. If anyone put same stuff as yours, you can put it on the post-it. 3. Write "Problem" stuffs that we need to improve. It goes same way like above.

Retrospective 3. Examine improvement plan. 1. Write "Try" stuffs to solve a "Problem" stuff. Think about "keep" stuff more progressive. Write one stuff per one post-it. Keep quiet while writing and Write within 3 minutes. 2. Put the post-it on the Try area, then read it for all members. It goes one by one until it completes.

Retrospective 4. Agreement of Improvement Plans. 1. Pick up "Try" stuffs that is executable during next sprint. 2. Move chosen stuffs to the Todo area. 3. Make agreements!

Sprint Planning • Most HARD ceremony(event). • Answer two topics • What can be done this Sprint? • How will the chosen work get done?

What can be done this Sprint? • • Pick up PBIs from PBL from the top of the list. • PBL should be ordered by priority, which PO decide. • Keep picking up PBI as long as your team can make a commitment. Commitment is important. • If you break your promise, …

How will the chosen work get done? • Make a Sprint Backlog. • Sprint Backlog consists of chosen PBIs and Tasks. • Break down PBI into small tasks. • Task has Summary and Estimated time. • Estimated time for a task should be less than 6 hours.

Sprint Planning 1.Determine development capacity in this sprint. • This is only a guide. http://agilereflections.com/tag/capacity/

Sprint Planning 2.Proposal of sprint goal from PO. • Ex. • Finish ten PBIs. • Release push notification. 3.Pick up a PBI from PBL from the top of the list. • It's the highest priority of the PBL.

Sprint Planning 4.PO explains PBI and developers ask questions to make an estimation for it. 5.Break down PBI into small tasks. 6.Estimate tasks using hour(s).

Sprint Planning 7.Repeat the process of estimation until developers feel that they can't commit to finish PBIs anymore or the capacity gets full. 8.Review sprint goal. 9.Make a commitment.

One more thing…

Definition of Done & Acceptance Criteria

Definition of Done • "Done" means differently by person. • Make sure everyone is on the same page. • This is a definition common to a project. • Improve “Definition of Done” in the Retrospective.

Definition of Done http://www.slideshare.net/UpekhaVandebona/sprint-47982593/61

• http://www.slideshare.net/UpekhaVandebona/sprint-47982593/61

Acceptance Criteria • “Acceptance Criteria” is a criteria for PO to accept if PBI is "done" or not. • Each PBI has its own “Acceptance Criteria”. • Make “Acceptance Criteria” in the Sprint Planning. • Write “Acceptance Criteria” on PBI.(Post-it)

Acceptance Criteria • Example PBI • As an internet banking customer • I want to see a rolling balance for my everyday accounts • so that I know the balance of my account after each transaction is applied http://nomad8.com/acceptance̲criteria/

Acceptance Criteria • Example acceptance criteria • The rolling balance is displayed • The rolling balance is calculated for each transaction • The balance is displayed for every transaction for the full period of time transactions are available • The balance is not displayed if a filter has been applied http://nomad8.com/acceptance̲criteria/

Any Questions?