The Scrum methodology of agile software development marks a dramatic departure from waterfall management. In fact, Scrum and other agile processes were inspired by its shortcomings. The Scrum methodology emphasizes communication and collaboration, functioning software, and the flexibility to adapt to emerging business realities — all attributes that suffer in the rigidly ordered waterfall paradigm.
Posted by admin under Scrum Basics
Sprint Planning Meeting
In Scrum, every iteration begins with the sprint planning meeting. At this meeting, the Product Owner and the team negotiate which stories a team will tackle that sprint. Time-boxed to four hours, this meeting is a conversation between the Product Owner and the team. That is, it’s up to the Product Owner to decide which stories are of the highest priority to the release and which will generate the highest business value, but the team has the power to push back and voice concerns or impediments. This is a good thing since the team may be aware of a legitimate impediment keeping the team from moving forward.
When the team agrees to tackle the work, the Product Owner adds the corresponding stories into the sprint backlog. If a team uses manual agile, this might be physically represented by moving a Post-It note or index card with a story written on it from the backlog into the sprint backlog. If a team uses an agile tooling solution, this might be represented in a number of ways. A tool my company uses, ScrumWorks® Pro, has a two-paned view of a project, in which the product backlog appears on the right and the sprint backlog on the left. Using an intuitive, drag-and-drop interface, the Product Owner can easily add stories to the sprint.
At this point, the Product Owner is typically asked to leave while the team decomposes the sprint backlog items into tasks. While the Product Owner is asked to leave so that the team can candidly discuss the work, he or she is still expected to be “on call” to answer questions, clarify acceptance criteria, or renegotiate. This meeting, which was previously called the sprint definition meeting, is also time-boxed to four hours to limit all sprint planning activities to a single day’s time.
Now that sprint goals are defined, the team is ready to get to work. Of course, other meetings also happen during the sprint, which I’ll discuss.
The Daily Standup
The heart of the Scrum process is the daily standup meeting, also known as the daily Scrum. No other meeting captures Scrum’s emphasis on communication and transparency quite like the standup. This meeting helps ensure that the entire development team is always on the same page. Every day, the Scrum team gathers together, usually in a team room or private office—to report on the progress made since the last meeting, goals for the next one, and any impediments blocking their path. These reports are often phrased as responses to the following three questions:
- What have I done since the last Scrum meeting (yesterday)?
- What will I do before the next Scrum meeting (tomorrow)?
- What prevents me from performing my work as efficiently as possible?
This meeting should not exceed 15 minutes. If members of the team need to discuss an issue that cannot be covered in that amount of time, it is recommended they attend a “sidebar” meeting following the standup. This allows team members to attend meetings that directly involve their work, instead of sitting through irrelevant meetings. Unfortunately, daily Scrums often last longer than 15 minutes. To compensate, many teams use stop watches or timers to uphold the time limitations. Also, to limit distracting small talk, many teams employ a talking stick or mascot, which a team member must hold to speak in the meeting. Upon finishing an update, the talking stick is then passed to the next team member, who reports, and so on.
When the daily Scrum meeting is held is for the team and Product Owner to decide, but most Scrum literature encourages teams to hold the meeting as soon as all the team members arrive in the morning.
Sprint Review and Retrospective Meetings
In Scrum, when the sprint ends, it’s time for the team to present its work to the Product Owner. This is known as the sprint review meeting. At this time, the Product Owner goes through the sprint backlog and asks the team to present its work. The Product Owner checks the work against the acceptance criteria to determine if the work is satisfactory or not. Even if only one percent of a story remains to be completed by a team, the Product Owner must reject the story as unfinished. Teams commonly discover that a story’s final touches often excise the most effort and time, so awarding partial credit for an incomplete story can contribute to a slanted velocity.
After the sprint review meeting, the team and the ScrumMaster get together for the retrospective meeting. During this meeting, the team considers three things: what went well, what didn’t, and what improvements could be made in the next sprint. Since the Product Owner sits this meeting, team members can speak frankly about the sprint’s successes and failures. It’s an especially important opportunity for the team to focus on its overall performance and identify strategies to improve its processes. Moreover, it allows the ScrumMaster to observe common impediments that impact the team and then work to resolve them.
posted by: scrum methodology
Leave a Reply
Scrum Training Series
- Do you REALLY want to learn Scrum? Try a 3.1-day CSM class with case studies. July 25, 2013
- Scrum based funding model – 20 percent May 9, 2013
- MJは６月と７月の２ヶ月間、日本に滞在する予定です。スクラムのコーチングまたはトレーニングに興味のある方は是非ご連絡ください。 March 14, 2013
- The Next Big Idea March 5, 2013
- On Being Available February 17, 2013