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.
10th
OCT
Scrum Sprint
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:
Comments Feed Reader's Comments
Leave a Reply
Recent Posts
- Scrum based funding model – 20 percent May 9, 2013
- What is Agile ALM April 2, 2013
- MJは６月と７月の２ヶ月間、日本に滞在する予定です。スクラムのコーチングまたはトレーニングに興味のある方は是非ご連絡ください。 March 14, 2013
- The Next Big Idea March 5, 2013
- On Being Available February 17, 2013
Events
Click to Follow Laszlo on Twitter
Archives
- May 2013
- April 2013
- March 2013
- February 2013
- January 2013
- December 2012
- November 2012
- October 2012
- January 2012
- December 2011
- November 2011
- October 2011
- November 2010
- September 2010
- June 2010
- April 2010
- March 2010
- February 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
iterative AND incremental delivery…. That’s the difference between RUP vs. Scrum
I suggest you take a peak at this video blog: http://www.youtube.com/watch?v=06qP6Lg2LvE
[...] e testes de aceitação, além de BDD favorecer a construção de aplicativos de forma evolutiva (sprints) e tudo isso casa perfeitamente com os requesitos das metodologias [...]
[...] that the idea of locking down requirements and schedules for even as short a duration as a 2 week sprint will be introducing a lot more workflow structure than we’re accustomed [...]
This is a good blog, I discovered your blog page browsing yahoo for a related subject matter and came to this. I couldnt find to much alternative information on this blog, so it was wonderful to find this one. I definitely will end up being returning to check out some other posts that you have another time.
[...] teams to break down projects into functionality that can be completed within a two week timebox, or sprint. There are two reasons to do this: 1) it forces the team to create smaller, acheivable goals and 2) [...]
Really, very nice stuff to get start up with Scrum method…….
[...] leverages small teams to deliver software increments through “sprints.” It was developed over the last decade by Ken Schwaber, Mike Beedle, Jeff Sutherland, amongst [...]
[...] environments. Scrum methodology teaches us to protect the team within time-boxed iterations (Sprints) What I’ve learnt in trying to tackle unplanned work without interrupting the Sprint, is that [...]
[...] seguinte chegar à empresa uma consultoria em Agile e começar a explicar Scrum, XP, User Stories, Sprints, TDD e uma série de outras técnicas e conceitos. Enquanto isso, o gerente provavelmente irá [...]
[...] have a very structured meeting schedule: A planning meeting at the beginning of each sprint (a sprint is a cycle which repeats and can be of any length — we typically do one week to two week [...]
So with all of these daily/weekly meetings, who is doing the work? When does the work ever get done?
Hey there! I could have sworn I’ve been to this site before but after browsing through some of the post I realized it’s new to me. Anyhow, I’m definitely happy I found it and I’ll be book-marking and checking back frequently!
[...] the system/environment/code itself will behave. You will soon realize that you need to have shorter sprints, because you want to deploy to production right after things are ready. Why do you have to wait for [...]
@Sam: We timebox the meetings. For instance, the daily meeting is 15 minutes long. Also consider the possibility that collaborating with each other is part of “doing the work.”
[...] this Sprint’s work increase or decrease code coverage? If we see a strong decrease, we might want to look at the [...]
[...] Det är svårt att i en bloggpost göra en ordentlig djupdykning i ett agilt Europa och det finns många aspekter att titta på. Jag ställer mig dock bakom Olli Rehns förslag och ser fram emot EUs första sprint. [...]