For many product and engineering teams, sprints are second nature. But what about teams outside of product? Are sprints worth exploring as a way to make progress across multiple work streams?
The Agile Sprint, a concept derived from project management methodologies, can be a powerful level-up for any team, as long as some tweaks are made to the standard agile sprint system.
Thanks for reading Notion Creators Weekly! Subscribe for free to receive new posts and support my work.Subscribed
A study from Broadcom – although focused on engineering teams – shows there are clear benefits to applying agile methods. A few key data points from the study:
Agile teams are 60% more productive than teams that do not use agile sprints.
Agile teams are 20% more likely to meet their deadlines.
Agile teams are 15% more likely to deliver high-quality products.
Whether you're managing a product development team, or coordinating marketing initiatives, sprints offer a structured approach to breaking down complex projects into manageable tasks. They enable focus, foster swift progress, and instill an iterative mindset across your organization.
However, the transition to sprints can come with their own set of challenges. It requires early inclusion of stakeholders, cross-departmental feedback, and dedicated sprint champions within each team. Let’s break down how your team can leverage them to maximize productivity and track progress efficiently.
At its core, a sprint is a short, time-boxed period during which a specific set of tasks are completed. Originally part of Agile and Scrum methodologies, sprints have transcended the realm of software development and are now widely adopted across various industries.
Sprints consist of four key components:
Throughout the sprint, team members collaborate to complete the tasks, review their work, and plan for the next iteration.
Importantly, sprints are not just for tech teams. They provide a structured way to tackle significant questions, test new business ideas, or solve critical challenges in a short span of time. Whether you're in marketing, sales, or operations, sprints can revolutionize the way your team works.
Agile sprints come with a variety of key terms that are important to understand to maximize their effectiveness. Here are the definitions of some of the most important terms to know:
Sprint burndown: A sprint burndown chart is a visual representation of the amount of work remaining in a sprint. The chart is typically plotted on a graph with the x-axis representing time and the y-axis representing the amount of work remaining. The goal of a sprint burndown chart is to track the progress of the sprint and to ensure that all of the work is completed by the end of the sprint.
Velocity: Velocity is a measure of the amount of work that a team can complete in a sprint. Velocity is typically measured in story points, which are a unit of measure that is used to estimate the complexity of a task. Velocity can be used to track the progress of the team over time and to make predictions about how much work the team can complete in future sprints.
Lead time: Lead time is the time it takes to complete a task from start to finish. Lead time includes the time spent planning, developing, testing, and deploying the task. Lead time can be used to track the efficiency of the team and to identify bottlenecks in the process.
Cycle time: Cycle time is the time it takes to complete a task from start to finish, excluding the time spent planning. Cycle time is typically shorter than lead time because it does not include the time spent planning the task. Cycle time can be used to track the efficiency of the team and to identify bottlenecks in the process.
Throughput: Throughput is the amount of work that a team can complete in a given period of time. Throughput is typically measured in story points per sprint. Throughput can be used to track the productivity of the team and to make predictions about how much work the team can complete in future sprints.
These terms are important to understand in order to track sprint progress and make informed decisions about how to improve team productivity.
A Note on Lead Time vs. Cycle Time
At first glance, lead time and cycle time may seem similar, but they’re different metrics used to track the efficiency of an agile team. They are both measures of the time it takes to complete a task, but they measure different things.
Lead time is the time it takes to complete a task from start to finish. This includes the time spent planning, developing, testing, and deploying the task. Cycle time is the time it takes to complete a task from start to finish, excluding the time spent planning. This means that cycle time is typically shorter than lead time.
Here is a quick breakdown on how they differ:
Metric Definition Includes Lead time The time it takes to complete a task from start to finish. Planning, development, testing, and deployment. Cycle time The time it takes to complete a task from start to finish, excluding the time spent planning. Development, testing, and deployment.
Lead time is a more comprehensive metric than cycle time, but it can be more difficult to track. Cycle time is a simpler metric to track, but it does not give a complete picture of the time it takes to complete a task.
Both lead time and cycle time can be used to track the efficiency of an agile team and to identify bottlenecks in the process. By tracking these metrics, teams can make informed decisions about how to improve their productivity.
Here are some examples of how lead time and cycle time can be used:
A team can track their lead time to see how long it is taking them to complete tasks from start to finish. If the lead time is increasing, it could indicate that there are bottlenecks in the process.
A team can track their cycle time to see how long it is taking them to complete tasks without planning. If the cycle time is increasing, it could indicate that the team is spending too much time planning tasks.
A team can compare their lead time and cycle time to see how they are performing relative to their goals. If the lead time is shorter than the cycle time, it could indicate that the team is spending too much time planning tasks.
Understanding Different Roles
In a sprint, there are three primary roles:
product owner: responsible for defining the sprint goals and managing the product backlog
scrum master: facilitates the sprint, removes obstacles, and ensures the team follows Agile principles
development team. can consist of professionals from various departments, executes the tasks in the sprint
At first glance, the product owner and scrum master roles may seem redundant, but they serve very distinct purposes. The product owner, likely a Director or VP, is defining sprint goals based on larger company goals and strategies, while the scrum master is focused on the day-to-day details on sprint progress. This person is also likely taking the lead on stand-ups, and communications when it comes to blockers or issues.
It's also important to note that there could be several concurrent sprints happening across the company at the same time. Sprints can also align to OKRs but don't necessarily need to.
How to Implement Sprints in Your Organization
Implementing sprints in your organization begins with defining your sprint goals.
Why does the sprint exist, and where do we want to be at the end of the sprint? This will vary largely by team, and goals will improve overtime, but the goal here is to make a clear statement as to where you want to be as a team at the end of the two week period.
Defining Action Items
Once the goals are set, you break them down into tasks during a sprint planning meeting. If your team organizes tasks by project sprints act as a third layer of organization. This can be helpful when mapping out sprints, allowing teams to execute tasks in batches, based on their parent projects.
The idea of daily standups may seem like a huge time sync, especially for larger teams that are aligning on Sprint progress, but standups play a critical role in quickly and succinctly sharing progress updates across each team member, and most importantly, highlighting any blockers or challenges that may put sprint completion in jeopardy.
Daily stand-ups ensure everyone is aligned, while sprint reviews and retrospectives provide opportunities for assessing and improving performance.
You can think of retrospectives as slightly more slightly deeper, standup meetings, giving your team the opportunity to reflect on the work, celebrate the team’s accomplishments, and identify areas for improvement, or areas that need to be prioritized going into the next sprint.
Throughout this process, remember that the success of your sprints depends on clear communication, team collaboration, and continual learning. Don't be disheartened by initial hiccups – they're part of the journey!
How do sprints work in Notion?
You may have seen Notion, recent update, called Notion projects, which incorporates sprint functionality directly into project and task management workflows.
But what you may not have known, is that sprints are easy to implement, even if you already have existing projects and tasks, databases set up.
If you're curious how notion projects work, check out my blog post on the topic.
If your team is brand new to Notion, and has not started managing projects in Notion, using notions template can be a great place to get started, and also to see how the sprints data is not only organized next tasks, but roles up key, data, like tasks, completed, progress across tasks.
If your team is already managing projects and tasks in Notion, setting up sprints is pretty easy:
Create a sprints database
Relate the sprints database to your tasks database
Create a sprint template page, with a linked view of the task database, filtered to only show tasks that are part of the parent sprint.
Create a second view, showing tasks grouped by project, which will be where you can assign tasks to the current or upcoming sprint
Optimizing Your Sprints
To extract the most value from your sprints, it's vital to measure performance and make necessary adjustments. This involves tracking key metrics such as completion rate and sprint velocity, conducting end-of-sprint retrospectives, and planning upcoming sprints with specific areas to prioritize.
Bear in mind that it can take several sprint cycles to get into an effective workflow, where sprints are ambitious, but achievable. Whether it's adapting to the fast pace of sprints or managing the diverse tasks within a sprint, these challenges can be tackled effectively by learning from each sprint and continually refining your approach.
Perhaps the biggest benefit of implementing sprints across every team is the huge gains in visibility for your company’s leadership team. Organizing tasks by project is still an effective way to track progress, but can be a siloed process, with little transparency across teams.