Overwhelmingly, the world is going agile – a whopping 71% of organizations have adopted agile planning methodologies, and 60% of those companies increased their profits after doing so.
In this article, we’re going to dive into what the approach is and its processes so you can apply it to your own workflows. Looking for an answer to a specific question? Click the links below to navigate to the following sections:
+ 4 essential Agile components
+ The agile planning process: step by step
For those wanting more of a step-by-step guide, let’s first define the term.
What is agile planning?
Agile planning is a project management style with an incremental, iterative approach. Instead of using in an in-depth plan from the start of the project—which is typically product related—Agile leaves room for requirement changes throughout and relies on constant feedback from end users.
Over a defined period of time, cross-functional teams work on product iterations and achieving OKRs (objectives and key results), organizing their work into backlogs that focus on delivering value. The ultimate goal of each iteration is to produce a working project.
One of the most popular agile planning strategies is Scrum. Next, we’ll quickly go over Scrum and what it means.
The Scrum approach to planning—how to start thinking in an Agile way
In this section, we’ll touch lightly on Scrum. You’ll see plenty of overlap between Scrum and Agile, so we’ll keep it brief here.
As mentioned above, Scrum follows the Agile planning methodology.
The main difference between Scrum and Agile is that while Agile is a project management style, Scrum is just one of various approaches to following that framework. Just as with Agile planning, its goal is to create a functional product that delivers value to the user.
In the Scrum approach, there’s plenty of room for continuous change and adaptations to user’s needs and changing markets. Here’s a short intro into how it works:
Scrum relies on sprints (more on this below) to work on product fixes, updates, new features, requirements, and so on. Just as in agile planning, this is called the product backlog. Every few weeks, the team chooses a few items from the backlog they’ll work on during the next sprint. Throughout the sprint, the team participates in events (called ceremonies) where the team:
- Plans each sprint and decides what to accomplish in the next sprint
- Gets team members on the same page and voices any concerns that may block progress
- Comes together at the end of the sprint to see a demo and what they accomplished
- Meets after the end of each sprint to talk about what worked well and what didn’t, so they can improve the process moving forward. This is called the Retrospective.
We’ll get into some of these stages below as we explore Agile more in depth in the following sections, starting with its essential characteristics.
4 Essential characteristics of Agile Planning
Before using any project planning method, such as Kanban boards, Gantt charts or Scrum, it’s important to understand the basics. Here are the four essential characteristics of Agile you need to know.
1. An agile project plan is divided into releases and sprints
Agile planners define a release as creating a new product or substantially updating an existing product. Each release is broken down into several iterations called sprints. Each sprint has a fixed length, typically two weeks, and the team has a predefined list of items to work through in each sprint. The work items are called user stories.
The release plan is broken down into several iterations (sprints) that include user stories (items).
2. Planning is based on user stories
As mentioned above, a user story is an item that caters to users’ needs. For example:
- “As a team member, I need to know which tasks are currently assigned to me.”
- “As a team leader, I need to receive an email notification when a task is stuck or behind schedule.”
Unlike in traditional project management methodologies like waterfall, in which teams would create detailed technical specifications of exactly what they would build, in agile planning, the team only documents what the user needs. Throughout the sprint, the team figures out how to address that specific need in the best way possible, which brings us to the next characteristic.
3. Planning is iterative and incremental
All sprints are of equal length, and an agile team repeats the same process over and over again (such as the ceremonies we outlined in the Scrum section) in every sprint. Each sprint should result in working features that can be rolled out to end-users.
An iterative process allows the team to learn what they are capable of, estimate how many stories they can complete in a given timeframe, and discover problems that impede their progress. These problems can be taken care of in subsequent sprints.
4. Estimation is done by team members themselves
A core ethic of agile planning is that development teams should participate in planning and estimation, instead of management deciding on the work scope. In this spirit stage, agile planning allows teams to determine the complexity of user stories to carry out a plan. In agile methodology, the process of defining work complexity is called a story point.
For example, a team can assign 1 point to a simple user story, 2-3 points for moderately complex, and 4-5 points for a big story – based on their understanding of the work involved.
Now that we know which elements you need for an Agile plan, let’s go through how you’d create yours.
The agile project scheduling process
To better understand how you’d go about creating an agile project schedule or plan, we created a step-by-step list of what you’ll need to do. After discussing the goals for the release— what problem do we want to solve or how will we improve the user experience?—you can use the following to plan your release.
- Discuss the needed features to address the goals. What components would make the product even more user-friendly? What are users missing? What would they like to see?
- Discuss the details involved in each feature, and factors that can influence delivery. This would include the infrastructure required, risk, and external dependencies. Features with highest risk and highest value should be planned early in the release.
- Decide how much work you can commit to as a team in each sprint. This is usually based on the team’s velocity in previous sprints. You should take into account existing work on infrastructure or tools, and known interruptions such as support work.
- List the stories and epics for the release by their size. An epic is a larger dev task broken down into several user stories.
- Add an iteration to the plan so teams know what they’ll work on for the following two weeks.
- Add stories to the iteration until it reaches the maximum capacity.
- Add more iterations until all user stories are covered, or remove lower priority user stories to adapt to the required time frame for the release.
- Share the plan using your agile management software of choice and ask for feedback to get commitment from all team members, product owners, and other stakeholders.
The above is all about deciding on the schedule, but you’ll still need a plan of attack for the actual sprints. Let’s look at what that entails.
Sprint Planning Process
Here is how an agile team plans a new sprint, as part of an existing release plan:
- Hold a retrospective meeting to discuss the previous sprints and lessons learned.
- Run a sprint planning meeting to analyze the release plan and update it according to velocity in recent sprints, changes to priorities, new features, or idle time that wasn’t planned for in the release.
- Make sure user stories are detailed enough to work on. Elaborate on tasks that are not well defined, to avoid surprises.
- Break down user stories into specific tasks. For example, the user story “view tasks assigned to me” can be broken up into UX design of a “my tasks screen”, back-end implementation, and front-end development of the interface. Keep the size of tasks small, no more than one workday.
- Assign tasks to team members and confirm that they are committed to performing them. In the agile/scrum framework this is done by the Scrum Master.
- Write the tasks on (physical) sticky cards and hang them up on a large board visible to the entire team. All the user stories in the current sprint should be up on the board.
- Track the progress of all the tasks on a grid, by recording who is responsible for completing each task, estimated time to complete it, remaining hours, and actual hours used. This time tracking should be updated by all team members and visible to everyone.
- Track velocity using a burndown chart. During the sprint, use the team’s time tracking to calculate a chart showing the number of tasks or hours remaining, vs. the plan. The slope of the burndown chart shows if we are on schedule, ahead, or behind schedule.
During the sprint, you need to ensure everyone is on the same page and teams communicate issues or potential issues. This is the purpose of the Daily Standup Meeting.
Daily Standup Meeting
Once you have the schedule down and you’ve planned your sprint, from the very beginning of the sprint you’ll gather the entire team and have every team member report on their status. There are a few components to these meetings:
- Daily agile planning meetings are typically standup meetings, to encourage brevity.
- They have a maximum duration of 15 minutes.
- Each member has no more than one minute to report “what I did yesterday,” “what I’ll do today,” “what’s in my way” from accomplishing the task on time.
- The task status can only be “done” or “not done,” and if it’s not done, team members should state how many hours remain to finish up.
- Obstacles encountered by team members should be briefly stated and discussed later in the relevant forum.
- The Scrum Master or release manager is responsible for coordinating and helping team members overcome obstacles.
We threw a lot of information at you regarding scheduling, planning, and running standups during your sprint. That’s a lot to take in, yet alone visualize how it could look. That’s why many teams use a Work Operating Software (Work OS) to help them run their projects, communicate with team members, and track all updates in real-time.
Using a team management tool for agile planning
A team management tool can help you define the user stories in the release, organize them into sprints, assign them to team members, and track progress in real-time, from anywhere. Here’s a quick visual of what this could look like in a work OS.
Though staging-mondaycomblog.kinsta.cloud is more than a team management tool, thousands of teams rely on our Work OS as their main agile project management tool to run all kinds of projects transparently and seamlessly. They use staging-mondaycomblog.kinsta.cloud’s Work OS to:
- Get a clear understanding of priorities and estimates, easily tracking transformation into reports and dashboards
- Plan sprints realistically with a number of visual options to help them see team capacity, individual capacity, user story statuses, and more.
- Know at a glance if something’s stuck, in progress, or behind schedule with colorful and customizable statuses.
- Sync entire teams on timelines and milestones, allowing anyone to tag another teammate to a user story or status so everyone stays in the loop.
- Visualize ownership of bugs and features with customizable boards that lets you filter by person, item, date, bug, and so on.
- Attach all documents, materials, and useful notes to one board, giving everyone one source of truth.
- Easily shift tasks around using our drag and drop functions as needed to reflect user requests or product changes.
All of the above is just the beginning of what you can achieve on staging-mondaycomblog.kinsta.cloud.
Use staging-mondaycomblog.kinsta.cloud for effortless agile planning
Agile planning’s structure and iterative approach to work makes it the perfect complement to product teams and various industries alike, though any team can use this method.
Once you have an understanding of how to use and maintain this methodology, take your agile planning to the next level on staging-mondaycomblog.kinsta.cloud‘s Work OS—not only will you always have a clear view into each sprint, but you’ll be able to reinforce Agile principles such transparency and agility every step of the way.
