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.

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. Scrum sprints used to be 30 days long, but today many teams prefer shorter sprints, such as one-week or two-week sprints.

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. 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 may require multiple sprints, each iteration of work builds on the previous. 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 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 the sprint, team members check in with each other at the daily Scrum meeting, also called the standup.

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.

The 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.

Watch videos of the Scrum meetings, or this overview:

 

Be Sociable, Share!
Comments Feed

Reader's Comments

  1. Mahesh Shete |

    Really, very nice stuff to get start up with Scrum method…….

  2. Sam Adams |

    So with all of these daily/weekly meetings, who is doing the work? When does the work ever get done?

  3. MJ |

    @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.”

  4. Gunslinger |

    Great high-level summary, well written. Our company just started this recently (on our 6th sprint now), and I was a little confused about the pacing, being a pig. Fixed me right up!

  5. Using Themed Work Weeks instead of Themed Work Days | David Seah |

    […] assessment. In particular, my planned approach reminds me of a “one week sprint” in the SCRUM methodology of “agile” software […]

  6. Rashi Jain |

    In a agile developement if the sprint is of 15 days and testing team receives the code on 12th day of the sprint.how the testing team should complete the testing

  7. MJ |

    In Scrum (and most other Agile approaches) there is no separate testing team. One cross-functional team is responsible for a properly tested product increment every Sprint. This means automated tests are written at the same pace as the code, or in Test Driven Development (TDD), automated tests are written a few minutes before the code that they test.

  8. DC |

    In scrum TDD is great idea and works really well, the query I have is in relation to System Test, Integration Test and performance testing, how do you ensure all that is covered in a 3 week sprint.How do you ensure the independence of test, in the case of In-team development test they are trying with the team to make the delivery but in the case of independent test they are trying to break the product. Both have different agendas, how do you ensure the quality of product for delivery when all other test is outside the sprint and thus break code after definition of done is met. Is there anything in agile for including system test, performance test etc in sprint and is that really possible in 3 weeks??
    Would welcome your thoughts?

Leave a Reply