1. Execute Iteration Planning Session
1.1. Present Agenda & Input
1.1.1. Definition of Done
1.1.1.1. User Story Definition of Done
1.1.1.1.1. Coded
1.1.1.1.2. Commented (if needed)
1.1.1.1.3. Design documents updated (if)
1.1.1.1.4. Code coverage more than 80%
1.1.1.1.5. Code review done
1.1.1.1.6. Tested
1.1.1.1.7. User Story state is Done
1.1.1.1.8. Available on Demo environment or any other environment on-demand using continuous delivery
1.1.1.1.9. Product Owner agrees on quality of product increment
1.1.1.2. Iteration Definition of Done
1.1.1.2.1. All User Stories are done by Definition of Done
1.1.1.2.2. More details will be defined by The Team & Product Owner after DoD for US is established strongly ...
1.1.2. Velocity Prepared
1.1.2.1. Last few relevant sprint
1.1.2.2. Team availability
1.1.3. Impediments Checked
1.2. Present Iteration to the Agile Team
1.2.1. Sprint basic info
1.2.1.1. Start
1.2.1.2. End
1.2.1.3. Name
1.2.1.4. Belongs to Release
1.2.1.5. Additional Info
1.2.2. Goal draft
1.2.2.1. Goal draft is communicated and agreed with the client
1.2.2.2. Typically a sentence or two stating the business objectives of the iteration, it should be clear but still abstract enough! What this means? It should be constructed as a story (not User Story) that presents and explains product increment that will be available to end user after sprint is finished. Also, The Team & Product Owner can refine it and adjust during planning.
1.2.3. Short intro about top priority stories that Product Owner finds important to to emphasize to complement the Goal draft.
1.3. Present & estimate individual User Stories
1.3.1. A Moderator, who will not play, chairs the meeting.
1.3.2. The product owner describes the top PBI before the team is invited to ask questions to clarify the scope and desired benefits. Any changes to the PBI description or acceptance criteria are captured progressively.
1.3.3. For each story, team has a short conversation to reach for a common understanding of business need it should provide and high level technical solution team will use. This conversation is tim-boxed.
1.3.3.1. Dev Team
1.3.3.1.1. Allow Product Owner to explain to the end.
1.3.3.1.2. Write down questions regarding Use Story and wait for your turn to ask a question.
1.3.3.1.3. Listen first, talk and ask questions after.
1.3.3.1.4. Do not interrupt others or force your insight as more relevant than others.
1.3.3.1.5. Try to understand, not to force you solution, consensus.
1.3.3.1.6. Avoid lecturing Product Owner about system, he/ she is involved in business needs an priorities better than others, it's his responsibility
1.3.3.2. If common understand is not reachable move on to the the next User Story and put this one back to the backlog or for latter (after a break, Product Owner can solve it quickly).
1.3.3.3. Technical solutions are irrelevant at this point, only HL design ideas are discussed if needed. If there is more than one design pattern, assume that team will use the most complex & acceptable one and estimate.
1.3.3.3.1. Remember resources files. We discussed about it number of times, spent a lot of energy, nerves and time ... And at the end we found great solution, a build in tool in Visual Studio.
1.3.4. Vote
1.3.4.1. Once ready to estimate, each team member places, face down on the table, the card he or she feels best represents the effort required to complete the PBI.
1.3.4.1.1. Relative estimation focuses on comparing rather than deconstructing.
1.3.4.1.2. Use relative estimation and estimate in Story Points.
1.3.4.2. Once they have chosen their cards, all team members simultaneously flip their cards face up.
1.3.4.2.1. If estimate are close to each other, the estimate with highest frequency is selected.
1.3.4.2.2. If estimates are diverging, team discusses the estimates to get a common understanding. This is time-boxed.
1.3.4.2.3. Cards are turned over again at the same time after discussion.
1.3.5. Until enough User Stories is estimated
1.4. Establish Sprint Backlog and refine the Goal
1.4.1. Product owner and team agrees on the final list of User Stories that will be included in the Iteration, and they revisit and restate the iteration goal.
1.4.2. Once more they consider all parameters. (DoD, - projected velocity, - impediments, - sprint goal draft, - sprint backlog, - etc.)
1.5. Agile Team and Product Owner commits
1.5.1. The entire team then commits to the iteration goals, and the scope of the work remains fixed for the duration of the iteration.
1.5.2. All US will be Done (DoD)
1.5.3. Iteration will be Done
1.6. We have done a GREAT JOB, thank you all :D
2. Product decisions are made by product owner and no one else. He is responsible for priorities, quality and deadliness.
3. Meeting Preparation
3.1. Product Backlog
3.1.1. Product Backlog Items - PBI
3.1.1.1. User Stories
3.1.1.2. Any stories that were not successfully completed (did not meet the Definition of Done)
3.1.1.3. Bugs
3.1.1.4. Technical constraints / Refactors / Re-architecting
3.1.1.5. Newly identified User Stories during planning
3.1.2. DEEP
3.1.2.1. Detailed Appropriately. User stories on the product backlog that will be done soon need to be sufficiently well understood that they can be completed in the coming sprint. Stories that will not be developed for awhile should be described with less detail.
3.1.2.2. Estimated. The product backlog is more than a list of all work to be done; it is also a useful planning tool. Because items further down the backlog are not as well understood (yet), the estimates associated with them will be less precise than estimates given items at the top.
3.1.2.3. Emergent. A product backlog is not static. It will change over time. As more is learned, user stories on the product backlog will be added, removed, or reprioritized.
3.1.2.4. Prioritized. The product backlog should be sorted with the most valuable items at the top and the least valuable at the bottom. By always working in priority order, the team is able to maximize the value of the product or system being developed.
3.1.3. No blocking dependencies or unclear items
3.1.4. Two iterations ahead
3.2. Iteration Goal draft
3.2.1. Should be communicated between Product Owner and Stakeholders. This is a next focus, next important thing to deliver or develop. Next thing that will bring the value.
3.3. Meeting Agenda
3.3.1. Prepare Time-boxing
3.3.1.1. Calculate average velocity and average number of stories done in a sprint. Use it to define US planning time range.
3.3.1.2. For two weeks sprint planning should not take more than 4 hours.
3.3.1.3. Take a 5 minute break every 30-35 minutes.
3.3.2. Sent to all participants before planning meeting session
3.4. Participants
3.4.1. Dev Team
3.4.1.1. Developers
3.4.1.2. QA members
3.4.1.3. Solution Architect (if needed)
3.4.1.4. DevOps (if needed)
3.4.2. Product Owner
3.4.3. Scrum Master
4. Output
4.1. Committed Iteration Backlog.
4.1.1. A commitment by the Team to the work needed to achieve the goals.
4.1.2. The iteration backlog, consisting of the stories committed to the iteration, with acceptance criteria where appropriate.
4.2. Refined Sprint Goal.
4.2.1. A statement of Iteration Goal, typically a sentence or two stating the business objectives of the iteration.
4.3. High level plan how to overcome technical challenges.
4.4. List of questions and User Stories that were not clear to Agile team.
4.4.1. If item's priority is high, Product Owner is responsible to clear it out with the team ASAP.
4.4.2. If priority is low it will be answered during iteration or during next planning session.