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.


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 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:


Comments Feed

Reader's Comments

  1. Peoria Osterelli |

    This is my 2nd company using this methodology. Very meeting intensive, get nothing done correctly technology. Break things rapidly and rapid personnel turn over… this leads to bad company hiring reviews and inability to hire people, ultimately locking you out of the market and ending up in the mercy of consultants. Meanwhile you pile crap up on your DBA’s to the point where they don’t even have time to review, while constantly losing your talent and knowledge base. Sure I want to use that technology. RAD = Rapid Application Destruction.

  2. MJ |

    Dave, what you’re describing doesn’t sound anything like collaboration to me. It sounds more like people handing off work to each other. The purpose of Scrum’s timeboxes is to expose things like that.

  3. MJ |

    Shailesh, I seem to be repeating myself, but in Scrum the build doesn’t “go to QA.” Testing is integrated throughout. Consider spending some time with the e-learning modules to get an idea how this works in practice. Also, why do you have a plan for the next 6 sprints? In Scrum we plan one Sprint at a time.

  4. Dave |

    @Rashi Jain – very fair point. I have just started with a team and at the sprint meeting the feature is discussed. Then someone goes off to spec the database changes and web service definitions, while the rest of us wait. Once the spec is done the middle ware guy and the web guy can write some code to the spec but there is a limit to what you can do without the layer below to build against. In my case our sprint meeting was a week ago. I wrote all the code to spec that I could in one day. The middle ware guy waited a few days for the database scheme to be settled, then started the webservices. I have been waiting for 6 days since the sprint meeting for the web services. That is a lot of waiting! Shouldn’t there be some sort of offset? I feel like I should be writing to their sprint 1 work while they start their sprint 2 data modeling.

  5. Shailesh |

    -If there is development there are going to be bugs, what should be the ideal timeline for a build to go to QA for a 2 weeks sprint?
    -What if bugs are reported post Sprint complete date, they goes as backlog ?
    -While planning for sprint, is it good idea to keep aside some efforts for bug fixing ?
    I have plan for next 6 sprints, but due to bugs reported my sprint is pushing, please suggest

  6. 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?

  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. Rashi Jain |

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

  9. 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!

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

  11. Sam Adams |

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

  12. Mahesh Shete |

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

Leave a Reply

Reload Image

Scrum Training Courses