Scrum Methodology
Learn the Scrum Methodology
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.
20th
AUG
Scrum Meetings
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
Comments Feed Reader's Comments
Leave a Reply
Newsletter Sign Up:
Recent Posts
- The Daily Scrum; It’s a Good Habit to Make
- Obstacles to Enterprise Agility
- What is Scrum?
- Can CSMs and PMPs Get Along?
- Orlando Scrum Gathering in March 2010
- Free Scrum Webinars
- ScrumMaster as Impediment
- Advice for Agile Adoption
- Share Your Story
- Free Agile Resources
- Advice for Extending the Sprint
- Danube’s New Scrum Video Blogs
- What Happens at Scrum Training?
- The CSM Exam Saga Continues…
- The CSM Exam
Categories
- Agile and Scrum (18)
- Scrum Basics (33)
- Scrum Discussion (20)
- Scrum Transitions (9)
- Uncategorized (6)
Archives
- June 2010
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
Blogroll
- Agile ALM
- Agile Methodology
- Agile Programming
- Agile Project Management
- Eric Brown
- Free Project Management Software
- IT Today
- PM Student
Danube on Twitter
- Overheard from a Twitter post by @sgamel
- Overheard from a Twitter post by @euro_latino
- Overheard from a Twitter post by @onion_soup
- Overheard from a Twitter post by @DarkSpooky
- Overheard from a Twitter post by @xiaoputi
- Overheard from a Twitter post by @jbuissing
- Overheard from a Twitter post by @andrewcmy
- Overheard from a Twitter post by @adrianoron
- Overheard from a Twitter post by @TheSoftwareGang
- Overheard from a Twitter post by @tshrinivasan


The Product Owner should not attend the Retrospective meeting, this is incorrect
“Since the Product Owner sits this meeting, team members can speak frankly about the sprint’s successes and failures.”
The sentance seems contradictive surely it should read
“Since the Product Owner does not sit in on this meeting, team members can speak frankly about the sprint’s successes and failures.”
Thanks for the correction, nfallon. You’re right. I omitted a word and it changed the meaning of my sentence. But to clarify, the Product Owner should NOT attend the retrospective, so that team members can speak candidly about what worked and what didn’t.
I like the exclusion of the product owner from the retrospective meetings;
However, in some organizations where the PO is internal, this is hard to do.
A ‘workaround’ that I saw working is having two ‘retrospectives’, one per scrum team (without the PO) and a latter one across multiple scrum teams, which includes product owners. This way, PO input is still received, but there is at least one session where views can be freely shared.