Also, some Product Owners may want to know what the "cost" of feature will be during development. So that you can let that Product Owner know the cost, the entire team should try to perform some kind of estimation. Planning Poker is one of the most effective ways to estimate. Using Wisdom of the Crowds, and looking at levels of effort, the team can give the Product Owner an idea of what one story costs in terms of time and effort.
Groom The Backlog
Once the backlog is prioritized, begin the grooming process. Grooming means that the Product Owner, Scrum Master, and perhaps with a Business Analyst or a team lead, determines the fate of stories. Stories that are in a low or unnecessary priority should be tossed.
New stories need to be taken to the team for more estimation. The team can give a quick level of effort estimation for these stories. Also, during these grooming sessions, the Product Owner can select a small subset of stories that could be in the next sprint. The other way to do this is to wait until the planning meeting and let the Product Owner select stories then. This is tough when the Product Owner and team are not collocated.
Plan Your Sprint
Rich communication among team members is a cornerstone of all agile practices, and Scrum is no exception. The planning meeting is an event with rich communication that starts each Sprint off. The frequency of this depends on the team. Select 1-4 week sprints. To have your sprint over the 2 week threshold may indicate that there is an issue. Most software projects can handle 2 week or less sprints. The exceptions to this may include coordination with another team, not using sprints, or support from another group only allows longer sprints.
During this planning meeting the Product Owner works with the team to select the stories to complete in the next sprint. As mentioned earlier, the Product Owner could come to the meeting with a preselected sub set of stories to select. The team communicates the level of effort they can commit to for that sprint. The Product Owner then selects the stories to be worked on for that sprint that total the level of effort indicated.
Here is a simple example. The Product Owner comes to planning meeting having a selection of stories that total 10 points. The Product Owner knows that last sprint the team completed 8 points of work. She is hopeful that the team may commit to more points, since they are bringing on a new team member.
In the planning meeting, the team is asked to commit to a number of points to complete for the sprint. The team states that they have discussed this, and can complete 7 points for the sprint. The Product Owner asks why the low commitment when they just completed a sprint with 8 points and are adding more resources? The team explains that the new resources will take some education time this sprint, learning how the team is implementing a new technology. Also, they explain, 2 members of the team have 2 days off this sprint. When they look at the actual amount of time to work this sprint it turns out to be less than last sprint, hence the 7 points.
The above example shows the type of negotiation and explanations that should take place when your team is planning. There is a lot of communication that goes on in Scrums, and the planning meeting starts this off.
Daily Scrum (Daily Standup)
The next rich communication experience is the daily standup. This meeting involves all team members. Stakeholders are welcome to attend, but the meeting is for sharing of information among team members.
The Scrum Master should set up the daily standup with all team members, and invite any other stakeholder to listen in. The daily standup lasts no longer than 15 minutes. In the daily standup, each team member reports on the following:
* What I worked on yesterday
* What I will work on today
* Any issues that are blocking me
Any other discussion can take place after the daily standup. But during the daily standup discussions of technical issues, clarifications of stories should not be allowed. This is to keep the meeting short. If those clarifications are needed, the participants will ask the involved parties to hang around after the standup to discuss these issues.
The retrospective allows all team members to discuss the process. These meetings occur when the sprint is over, usually the day before the planning meeting. The retrospective allows the team to look at their sprint from a distance. The team explores what went well, and what did not go well.
It may make sense to demo the completed software before the retrospective. This allows the team to show to business owners what they could currently release if they wanted. It also reminds the members what they worked on earlier in the sprint.
The Scrum Master needs to set up a demo meeting where all are invited. It is highly recommended that invitations are sent to all affected business areas, as well as the Product Owner and the Team members, who will present. Make the demo a good time, with the team showing off what they have accomplished this sprint.
After the demo, send out an invitation to all team members, including the Product Owner, for the Retrospective. Now the team can adjust for the next sprint, keeping what worked, and what did not work. To conduct the Retrospective, the Scrum Master should ask each team member, what worked and what did not work.
An effective way of doing this can be to ask for 3 things that worked and 3 things that did not work in the current sprint. Write those down on a white board. At the end of the Retrospective, assign action items to help improve what did not work. The team is ready for the next Sprint!
You can use the above steps to start using Scrum. The best way to start Scrum would be to get a good Agile Coach in to help start your new process. Below are some recommended readings. Using the people from these resources would be a good place to start looking for an Agile Coach if you are so inclined.
Whether you do or do not get a coach, get some of all of the recommended books shown below.
Succeeding with Agile: Software Development Using Scrum By Mike Cohn
Agile Estimating and Planning by Mike Cohn