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
In the Scrum method of agile software development, work is confined to a regular, repeatable work cycle, known as a sprint or iteration. In by-the-book Scrum, a sprint is 30 days long, but many teams prefer shorter sprints, such as one-week, two-week, or three-week sprints. But how long each sprint lasts is something for the team to decide, who must weigh the advantages or disadvantages of a longer or shorter sprint for their specific development environment. The important thing is that a sprint is a consistent duration.
During each sprint, a team creates a shippable product, no matter how basic that product is. Working within the boundaries of such an accelerated timeframe, the team would only be able to build the most essential functionality. However, placing an emphasis on working code motivates the Product Owner to prioritize a release’s most essential features, encourages developers to focus on short-term goals, and gives customers a tangible, empirically based view of progress. Because a release requires many sprints for satisfactory completion, each iteration of work builds on the previous. This is why Scrum is described as “iterative” and “incremental.”
Every sprint begins with the sprint planning meeting, in which the Product Owner and the team discuss which stories will be moved from the product backlog into the sprint backlog. It is the responsibility of the Product Owner to determine what work the team will do, while the team retains the autonomy to decide how the work gets done. Once the team commits to the work, the Product Owner cannot add more work, alter course mid-sprint, or micromanage.
During the sprint, teams check in at the daily Scrum meeting, also called the daily standup. This time-boxed meeting gives teams a chance to update project status, discuss solutions to challenges, and broadcast progress to the Product Owner (who may only observe or answer the team’s questions).
Just as every sprint begins with the sprint planning meeting, the sprint concludes with the sprint review meeting, in which the team presents its work to the Product Owner. During this meeting, the Product Owner determines if the team’s work has met its acceptance criteria. If a single criterion is not met, the work is rejected as incomplete. If it satisfies the established criteria, then the team is awarded the full number of points.
Because certain sprints are hugely successful and others less than ideal, a team also gathers at the end of each sprint to share what worked, what didn’t, and how processes could be improved. This meeting is called the sprint retrospective meeting.
posted by: scrum methodology
Watch videos of the Scrum meetings, or this overview:
Leave a Reply
Scrum Training CoursesApril 28 - 29, 2014
Gregory Smith, CST
May 01 - 02, 2014
Rafael Sabbagh, CST
May 08 - 09, 2014
Washington D.C., VA
Certified Product Owner Course
Petri Heiramo, CST
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