Sprint Planning

Before the start of each sprint, a planning meeting is held to determine which features will be included in the sprint. Features come from the product backlog, which is prioritized by the product owner. The first time that this meeting occurs on a project the product backlog is created. You can think of this as sprint 0. The user stories chosen by the product owner to be included in the sprint are given to the team and through a tool called Planning Poker, they are resized to show the complexity of a story related to the other stories in group (this will be further discussed in the following section). Once the user stories are sized, they are turned into a number of tasks by the team and a time estimate on how long each task will take is determined. Once all this is done, the team will look at the entire list of submitted work for the sprint and decide if they can commit to completing the work by the end of the sprint. To decide this, the team does a five-finger vote to gauge individual members� opinions.
A team member simply raises his hand and through the number of fingers he is holding up, he displays what bests reflects his confidence level. A hand value of a �1� means that the team member is very doubtful of the proposal. A hand value of a �5� means the team member is extremely confident in the proposal. If no one holds up a value of a �1� or �2� then the team commits to that work for the sprint. If a value of �1� or �2� is shown, then the team discusses why that team member voted this way and adjusts the proposal accordingly.

Once the team commits to delivering the list of user stories and tasks within the sprint, the ScrumMaster enacts a change freeze to allow the team time to develop the user story as written before any changes can be made (to prevent scope creep). A sprint backlog is made up of all the user stories and tasks required to complete the sprint. All members of the team, including the ScrumMaster and the product owner, are involved in sprint planning meetings. Once the planning meeting is over, the team will get together without the product owner to discuss the high-level design of the system.


Planning Poker
Planning Poker is a game that encourages the team members to give their honest assessment of the complexity of a user story in relation to other stories. The tools required for the game are simple: you can use your hand or purchase a set Planning Poker cards to handle it.

To play this game, the product owner will read the user story and explain it to the team. The team is free to ask questions about the story. Once all the questions have been answered, the ScrumMaster will ask the team to privately determine a number that best represents the complexity of the story. Team members should not share their numbers with anyone in order to prevent inadvertently influencing other team members. Once the team members have each come up with a number, the ScrumMaster asks everyone to reveal their numbers. If all the team members decided the same number, that number is assigned to the user story and everyone moves on to the next one. If the numbers do not match, then the team members with the lowest number and the highest number are asked to explain why they selected the number that they did.

After the discussion, another round of poker is played with each member deciding on a number for the user story. This goes on until the team has unanimously settled on a number. On average, there will be no more than three rounds to agree on numbers. If at the end of three rounds there is still no consensus, however, we suggest that the ScrumMaster take the number in the middle and move on to the next user story.

Planning Poker accomplishes a conversation about a user story among the entire team. When this discussion occurs, �rabbit holes� and �gotchas� are usually avoided for the developer.


Daily Stand-Ups (Scrums)
During a sprint, the team, the ScrumMaster, and the product owner commit to meeting once daily in the same place and at the same time to discuss any issues that are preventing work from being done.
Meetings are held with everyone standing and time boxed to no longer than 15 minutes. Anyone interested is invited to attend these meetings; however, only the people classified as Pigs are allowed to speak at these meetings. At the meeting, each team member answers the following three questions:

� What have you done since yesterday?
� What are you planning to do today?
� Do you have any problems preventing you from accomplishing your goal? What progress has been made on existing impediments? Can the blockage be removed or must it be escalated? (The ScrumMaster looks after this area.)

To keep the meeting from becoming a long, drawn-out ordeal and to stay within the 15-minute time box, team members agree to meet after the meeting to further discuss any problems raised during the stand-up. The daily stand-up meetings are about team members committing to work and giving a platform to talk about issues early in the process.


Sprint Review
The sprint review is held at the end of the sprint. Its purpose is for the team to present the user stories it has completed during the sprint. The team, product owner, and ScrumMaster are present at the review, along with any interested parties�especially managers and customers. The review consists of an informal demo of the developed software as it stands at the end of the sprint. This product demo meeting is a chance for the customer to give feedback on the product to the team. This opportunity for the customer to see the product and provide feedback on it gives the customer the chance to see a return on investment that was not possible in the waterfall development process. The aim of the review is to show the actual working software; there should be no formal slide show presentation or masses of preparation for this review. This meeting aligns with the agile principle of satisfying the customer through early and continuous delivery of valuable software.


Sprint Retrospectives
Along with the sprint review, a sprint retrospective occurs at the end of a sprint. The sprint retrospective is an opportunity for the team to reflect on the sprint that was. This is the team�s chance to congratulate itself for the things that went well and discuss the things that went wrong. This is an open area where the team should feel free to discuss any issue that affects the team and their ability to deliver the product to the customer. During this meeting, the entire team is present, including the ScrumMaster and the product owner.

At the beginning of this meeting the ScrumMaster gives each person three stacks of Post-it notes in three colors. One color is designated to mean �things that went well during the sprint;� another color is designated to mean �things that were confusing during the sprint;� and the third color is designated to mean �things that were bad during the sprint.� The group is then given a time box (three to five minutes) to write down as many thoughts as they can about the sprint onto the Post-it notes. This is quiet time with everyone writing. Once the time is up, all the notes are gathered and put on a wall in the office room. The cards are then organized into similar categories. As time progresses on the product, you start to see some common categories that come up with every sprint.

The ScrumMaster reads the notes for each category and the team discusses them. If during the discussion an action item is presented, the ScrumMaster will write it down. Once the team has finished discussing the category, the ScrumMaster will move on to the next category. This is done until all the categories are discussed.

Toward the end of the meeting, the ScrumMaster reads all the action items that were presented and the team assigns members to be responsible for making sure the action items get addressed.

This is a good time for the team to try new ideas on how to fix problems. Do not be afraid to try something new with a sprint. If it does not work for the team, then throw it out and try something else. This meeting aligns with the agile principles of continuous improvement of practices and process, and owes much to Lean principles.

Source of Information : Pro Agile .NET Development with SCRUM