The Scrum approach to agile software development marks a dramatic departure from waterfall management. Scrum and other agile methods were inspired by its shortcomings. Scrum emphasizes collaboration, functioning software, team self management, and the flexibility to adapt to emerging business realities.
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. Scrum sprints used to be 30 days long, but today we advise one-week or two-week sprints. If a team has trouble doing a two-week sprint, we suggest trying a one-week sprint to see where the snags are.
During each sprint, a team creates a potentially shippable product increment, 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. 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. Scrum is iterative and incremental. Because a release may require multiple sprints, each iteration of work builds on the previous (incremental), often replacing/discarding some of the previous work as more is learned (iterative).
Every sprint begins with the sprint planning meeting, in which the Product Owner and the team(s) 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 or micromanage. The Product Owner can cancel a Sprint, which shouldn’t happen often, and would usually occur due to a sudden change in business needs.
During sprint execution, the team develops code and automated tests simultaneously, ideally using techniques such as Test Driven Development (TDD), pair programming, and continuous integration. Agile teams also learn to automate their system testing, performance testing, load testing, etc. so the product can be completely shippable every sprint, whether or not it has all the features it will ultimately need. This type of collaboration is more likely to occur in a team room. Good scrum teams are cross functional, meaning they have skills in development, testing, business domain (requirements) expertise, UI skills, etc. They focus on learning rather than traditional microefficiencies. Agile approaches minimize handoffs and phases.
During the sprint, team members check in with each other at the daily Scrum meeting, also called the standup.
After sprint execution, we conduct a sprint review meeting, in which the team demonstrates the potentially shippable product increment to the Product Owner and everyone else who’s interested.
The team also gathers in private at the end of each sprint to reflect on how things went and what they’d like to change. This meeting is called the sprint retrospective meeting.
In Large Scale Scrum, sprints are similar, but there are multiple teams pulling work from one Product Backlog, prioritized by one Product Owner (usually with advisors). Multiple backlogs and Product Owners are harmful to large scale agility. Also teams are responsible for their co-ordination with the world outside them, including other teams. Scrum does not use traditional co-ordination roles such as project manager and PMO, as these interfere with team self organization.
Watch videos of the Scrum meetings, or this overview:
Leave a Reply
Scrum Training Series
- Scrum based funding model – 20 percent May 9, 2013
- The Next Big Idea March 5, 2013
- On Being Available February 17, 2013
- Should Scrum Always Require the Product Owner to Attend the Sprint Retrospective Meeting? February 5, 2013
- Happiness Metrics January 23, 2013