A sprint is the basic unit of development in Scrum.
- The sprint is a “timeboxed” effort; that is, it is restricted to a specific duration. The duration is fixed in advance for each sprint and is normally less than 30 days, although two weeks is typical.
- Once agreed, the timelines of the Sprint “deadline” cannot be changed. The Sprint duration can be changed over the life of the project.
- Each sprint is started by a planning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint goal is made, and ended by a sprint review-and-retrospective meeting, where the progress is reviewed and lessons for the next sprint are identified.
- Scrum emphasizes working product at the end of the Sprint that is really “done”; in the case of software, this means a system that is integrated, fully tested, end-user documented, and potentially shippable.
Scrum break work into small increments with minimal planning and do not directly involve long-term planning. Sprints are short time frames (timeboxes) that are typically less than 30 days. Each Sprint involves a cross-functional team working in all functions: planning, requirements analysis, design, coding, unit testing, and acceptance testing. At the end of the Sprint a working product is demonstrated to stakeholders. This minimizes overall risk and allows the project to adapt to changes quickly. An Sprint might not add enough functionality to warrant a market release, but the goal is to have an available release at the end of each iteration. Multiple iterations might be required to release a product or new features.
Analogy of Incremental and Iterative
Let us say, we want to draw a Mona Lisa.
First Approach : Break the idea into multiple pieces and construct piece by piece – This is Incremental
Second Approach : Draw a pencil sketch, take feedback from customer, refine the concept and build. This is Iterative.
Scrum is a iterative and incremental way of doing things.
Length of Sprint
Based on the various inputs including business requirements and release planning Schedule, the Product Owner and the Scrum Team decide on the Length of Sprint for the project. Once determined, the Length of the Sprint often remains the same throughout the project.
However, the length of sprint may be changed if and as the Product Owner and Scrum Team deem appropriate. Early in the project they may still be experimenting to find the best Sprint Length. Later in the project a change in the length of Sprint normally means it can be reduced due to improvements in the project environment.
Factors affecting Sprint Duration
- The length of release being worked on
- Uncertainty : Higher the uncertainty shorter should be the Sprint
- Ease of getting feedback
- How long priorities can remain unchanged
- Willingness to go without feedback
- The overhead of iterating
- The feeling of urgency is maintained
Video on Sprint Length
Protecting a Sprint
- Once the planning of the Sprint is done, the plan should be protected and not changed. Even if there are urgent changes requested by customer, the Scrum Master should explain to the customer to hold on until the end of the Sprint.
- The ScrumMaster must protect the team from disruptive outside influences. (Examples include sales people directly requesting estimates from team members for prospective clients, support staff directly contacting team members for help with customer bugs, consultants at client sites calling team members with installation, conversion, or configuration problems for a new installation, etc.) Even if a team member is truly needed in these situations, the ScrumMaster must provide a filter.
- The Scrum Master must also protect the team from attending unnecessary meetings. Most meeting owners will be able to tell if a team member really needs to attend a meeting. If so, the ScrumMaster should still be the filter.