A Sprint is an iteration in which the development team (developers and QA) works on the Sprint Backlog. During this time, the Product Owner must be available to answer questions and provide feedback on features as they evolve. At the end of the Sprint, the development team has the responsibility of providing potentially shippable code. Potentially shippable code means code that has been written, tested, and is ready to go to production, even if it will not go to production immediately. Scrum recommends that the team gives a demonstration to the Product Owner of the software with the new features at the end of the Sprint.
A Sprint typically lasts either 2 weeks or 30 days. Early literature about Scrum recommended 30 days but most teams do 2-week Sprints lately. I prefer two-week Sprints for various reasons. First, it's easier for the team to plan, estimate, and complete two weeks of work than four or six. A shorter time period also shortens Sprint planning meetings and tends to make estimates more accurate. Two-week Sprints also allow the Product Owner freedom to change priorities more often, which helps the team adapt to market pressures quickly.
Whatever time frame you chose for your Sprints, make sure they are time boxed. Time boxing gives the team a tangible goal (for example, at the end of two weeks you'll have these four new features completed.) People work better when they know they can succeed and when there is an end in sight. Forcing teams to have potentially shippable code at the end of every Sprint also prevents teams from going into a perennial "85% done" state where the team is always very close to completing a task—but it never gets done. Time boxing also encourages the team to keep the system stable since they know there is a checkpoint at the end of the Sprint in which they will need to demonstrate a working, potentially shippable version of the system. This is good for the development team, the Product Owner, and the customers.
Keeping the duration of the Sprint constant for the entire project is also a good practice because it provides rhythm to the team.
Product Owners cannot add more work to a Sprint once it gets started. They must delay new requirements until the next Sprint planning meeting. However, because Sprints are usually short, and include what the Product Owner thought was most important, Product Owners are typically receptive to the idea of waiting until the Sprint ends to change priorities. Remember that they can reprioritize on each Sprint planning meeting. It is possible to stop and cancel a Sprint in progress if the Product Owner cannot wait, and priorities must be changed in the middle of the Sprint. In my experience this happens rather infrequently in Scrum.
Scrum is also different from other software development processes in that neither the ScrumMaster nor the Product Owner assigns specific tasks to the development team. In Scrum teams, after the Sprint Backlog has been defined, the team members decide among themselves how to accomplish it. Some teams prefer to pre-allocate all items among themselves during the planning meeting, while others allocate only a handful of items, and members pick up the remaining items as they complete the first ones.
The ScrumMaster's main job during the Sprint is to make sure the team's needs are met, and to remove roadblocks. This includes ensuring that developers and QA have access to all necessary resources (people, documents, hardware, software). They also facilitate meetings with external parties, reduce distractions (such as people working on things not part of the Sprint Backlog), and coach the Product Owner and development team when decisions must be made. All in all, they make sure that developers and QA are working in the best possible environment.
The Product Owner needs to be easily accessible during the Sprint to answer questions about Sprint Backlog items, review work in progress with the development team, and make sure features are moving in the right direction.
For the duration of the Sprint, developers and QA work with each other on a daily basis. In some teams, QA works side-by-side with developers to design, develop, and test features, while in others they test features within a few hours of development (not weeks later). This tight loop between developers and QA is critical to ensure potentially shippable code at the end of the Sprint. Code that was written but not tested is very unlikely to be potentially ready to be shipped to production.
During the Sprint, team members get together on a daily basis to report their status to the team. The Scrum daily meeting—or daily scrum—is a short meeting time boxed at 15 minutes in which each participant answers three questions:
- What did you do since the last daily meeting?
- What will you do from now until the next daily meeting?
- Are there any roadblocks in your way?
Although the entire team is present at the daily meeting, it is very important to notice that the daily meeting is for team members to report status to their peers
, not to the ScrumMaster or the Product Owner. This meeting keeps the pace of the team visible on a daily basis to everybody involved on the team. If the team is moving along as planned it will be evident during these meetings. Likewise, if someone is having difficulties it will not go unnoticed. Frequent peer reporting helps teams self-organize efficiently as the Sprint progresses, and provides accountability among team members. It is important for the Product Owner and the ScrumMaster to be present in this meeting to detect roadblocks and act on them as soon as possible.
As an example, during a typical daily meeting one developer might report that yesterday he completed the middle-tier component for a particular module, and today he plans to wrap up the web page that will use it. He will inform the Product Owner and QA that they should be able to take a look at it the next day. Another developer might report that she is having trouble finding the root of a problem in the login process, and could use some help. QA might report that the contacts screen seems to be broken as a result of a fix in another module, and that the developers need to fix that before they can continue testing other screens on the same module.
To keep the meeting short, discussions that only involve one or two team members, or that might take more than a few minutes need to be scheduled outside the daily scrum. It is common for the daily meeting to be a stand-up meeting. This helps to keep the meeting short since people usually do not like to stand for more than 15 minutes.