What is a sprint and how is it managed?
Delivering working software quickly and regularly is a fundamental principle of agile development. This is accomplished using an iterative and incremental approach that enables development teams to work in short, repeatable cycles and deliver small chunks of new functionality.
While agile itself is a guiding set of values and principles, it has become an umbrella term for several software development methodologies, including scrum, kanban, and XP. These methodologies share the same philosophy but vary in their processes, practices, and terminology.
Scrum is the most widely adopted agile methodology. It provides an adaptive framework that enables product teams to deliver customer and business value on a frequent cadence. There are four key meetings or “ceremonies” that drive the process. These are the sprint planning meeting, the daily scrum, the sprint review meeting, and the sprint retrospective.
What is a sprint?
In scrum, a sprint is a fixed-length iteration of work that typically lasts between one and four weeks. During this time-box, the team builds and tests a clearly defined set of functionality with the goal of completing a useable and potentially shippable increment of work.
As a product manager, if your development team aspires to become more agile and wants to practice scrum, it is helpful to understand how a sprint is typically managed. This will help you work effectively with the team to deliver functionality that customers really want.
Who manages a sprint?
The scrum process defines three key roles in sprint planning and implementation.
- Product owner
- Responsible for maximizing the value of the work completed by the development team. The product owner prioritizes the backlog, defines user stories, and is the only team member empowered to accept stories as done.
- Scrum master
- Responsible for ensuring the process follows agile principles and values. The scrum master serves as a facilitator and coach who removes impediments, creates an effective working environment, and protects the team from outside interruptions.
- Scrum team
- Responsible for implementing the work. The scrum team functions as a self-managed team that includes all of the roles required to complete the work, including architects, designers, developers, and testers.
In some organizations, the product manager assumes the role of product owner, while in others, they are two separate roles. In this situation, roles are often distinguished by internal versus external responsibilities. The product manager focuses on achieving product success by deeply understanding customers, competitors, and market forces. The product owner is the go-to person for internal teams — particularly engineering.
How is a sprint planned?
Each sprint starts with a planning meeting. The purpose of the meeting is for the product owner, scrum master, and development team to agree on a set of items in the product backlog that will be completed during the sprint.
Prior to the planning meeting, product owners ensure that the backlog is groomed and prioritized correctly. This is a good opportunity for the product manager to work with the product owner to review the roadmap and discuss priorities.
Use a features roadmap to guide your sprint planning. Show the theme of your release and the strategic importance of user stories.
To help the planning meeting go smoothly, make sure that:
- The product backlog is prioritized with the most important work items at the top.
- Each feature or user story is small enough to be completed within a sprint and includes detailed requirements and acceptance criteria.
- Each user story has an estimate to help with capacity planning.
During the meeting, a sprint goal is established to ensure that the work selected delivers significant value, such as providing a new feature or mitigating a risk. Items are selected from the top of the product backlog and moved to the sprint backlog. The team determines how much work they can commit to based on their development velocity and availability of the team. The group reviews the requirements, including the definition of “done” for each, and raises any impediments to completing the work.
Once there is consensus on the plan, the team breaks down the work to identify the technical tasks and any dependencies. By the end of sprint planning, the team should have a clearly defined plan to meet the sprint goal so that they can begin implementing immediately.
How is a sprint managed?
As the sprint gets underway, scrum teams use a task board to manage their work. Progress is tracked using a sprint burndown chart. Each day the team meets for a short standup meeting, known as as the daily scrum. They share what they accomplished the previous day, what they intend to do today, and any impediments blocking their progress.
User stories must be completed to the satisfaction of the product owner. The product owner stays engaged throughout the sprint to answer questions, provide feedback, and ensure that the acceptance criteria are met.
What happens at the end of the sprint?
The sprint ends when the time-box ends, regardless of whether all stories are complete. A review meeting is held during which the team shows what they accomplished, typically in the form of a demo. The product owner and other key stakeholders provide feedback, and the product owner determines if the sprint goal has been achieved.
In a separate retrospective meeting, the team discusses the highs and lows of the sprint and identifies opportunities for future improvement.
Is a sprint the same as a release?
A sprint should not be confused with a release. A sprint is a time-box for completing a defined set of work, whereas a release brings a new product experience to market once it is ready to be delivered.
A product release can occur at the end of a sprint or after several sprints. Regardless of your release cadence, your plan must consider all of the cross-functional activities needed to support the release, such as those belonging to product, sales, support, ops, and marketing.
Many agile teams find that sprint and release burndown charts are helpful to visualize the team’s progress and the work that is remaining.
Monitor the real-time progress of a sprint or release and the remaining work. See status, burnup, and burndown measured against your pre-determined timeframes.
What tools support sprint management?
There are many tools available to support your agile development processes. From defining your strategy, to scheduling sprints, and managing the day-to-day tasks, it is important to choose tools that support the way your teams work.
|Tool type||How it helps||Examples|
|Product management||Define your strategy and create visual roadmaps that show how you will accomplish your goals. Manage your product backlog and prioritize features and user stories for release.||Aha!|
|Agile project management||Schedule, track, and manage your sprints using purpose-built agile project management tools. These support agile principles and practices and offer agile reporting and metrics.||CA Agile Central (formerly Rally), Jira Agile, and Pivotal Tracker|
|Task management||Visualize and manage all work in progress during each sprint. Teams update the task board continuously to reflect the status of the work.||Trello, Asana, kanban tools, and physical white boards|
We recommend integrating your product management tool with your agile project management and task management tools so that you can seamlessly connect your product strategy with the execution.
This approach empowers each team to use their tool of choice, while ensuring smooth handoffs and synchronized updates. Development teams benefit from understanding how what they are working on fits into the bigger picture. And product managers benefit from live status updates as the development team makes progress during each sprint.