Agile planning: a step-by-step guide
Overwhelmingly, the world is going agile – a whopping 71% of organizations have adopted agile methodologies, and 90% of agile projects have faster time to market than the average for traditional project management. A key contributor to the success of agile is a different approach to planning.
What is agile planning?
Agile planning is a project planning method that estimates work using self-contained work units called iterations or sprints. Sprints are periods of 1-3 weeks in which a team focuses on a small set of work items, and aims to complete them. Agile planning defines which items are done in each sprint, and creates a repeatable process, to help teams learn how much they can achieve.
How is agile planning and estimation different?
It breaks down software development into small, self-contained units which can deliver value to a customer. Teams don’t try to plan the “big product” all at once. They plan for what they can accomplish to satisfy a customer in a short period of time.
In this post we provide a step-by-step guide to breaking your project down and planning in small iterations, to deliver reliably every time.
4 essential components
1. An agile project plan is divided into releases and sprints
Agile planners define a release, which involves creating a new product or substantially updating an existing product. Each release is broken down into several iterations, also called sprints. Each sprint has a fixed length, typically 1-2 weeks, and the team has a predefined list of work items to work through in each sprint. The work items are called user stories.
2. Planning is based on user stories
A user story briefly describes a need experienced by your users. 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 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 together how to address that specific need in the best way possible.
3. Planning is iterative and incremental
The agile process is focused on the concept of iteration. All sprints are of equal length, and an agile team repeats the same process over and over again 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 (the team’s velocity) and learn about 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, and not have the work scope “dictated” to them by management.
In this spirit, agile planning allows teams to assign story points to user stories in the release plan.
What is a story point?
In agile methodology, a story point is a number which reflects the complexity or amount of work involved in developing a user story. 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.
An alternative estimation unit for agile stories is ideal time: how long a user story should take to develop, assuming zero interruptions.
Agile planning poker is an estimation game used by some agile teams. Several team members are asked to estimate a user story by drawing a playing card with a number of story points, and placing it face down on the table. Then cards are then turned face up, and if there are discrepancies – for example, one team member estimated 1 point and others estimated 4 or 5, they can discuss and reach a consensus.
The agile planning process: step by step
Release Plan Process
First, your product owner must lay out the goals for the release: what problem do we want to solve or how will we improve the user experience? Based on these goals, follow these steps to plan the release:
- Discuss the needed features to address the goals.
- 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, to finishing 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 in priority order with their size. An epic is a larger dev task broken down into several user stories.
- Add an iteration to the plan.
- 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 owner and other stakeholders.
Sprint Planning Process
Here is how an agile team plans at the beginning of a new sprint, as part of an existing release plan:
- Do 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 size of tasks small, no more than one work day.
- 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 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.
Daily Standup Meeting
Daily meetings are crucial to communicating progress, identifying and solving issues during a sprint. Every day, gather the entire team and have every team member report on their status:
- Daily agile planning meetings are typically stand up meetings, to encourage brevity.
- Maximum duration of 15 minutes.
- No more than one minute for each member to report: “what I did yesterday”, “what I’ll do today”, “what’s in my way” – things preventing someone from finishing a task on time.
- Status can only be “done” or “not done”, and if not done, how many hours remaining.
- 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.
Using a team management tool for agile planning
Although agile planning makes you think of physical boards and post-it notes, an agile management tool can be a big help. A tool can help you define the user stories in the release, organize them into sprints, assign them to team members, and track progress.
We have all kinds of teams that use monday.com as their main agile project management tool. They use the tool to:
- Get a clear understanding of priorities and estimates
- Plan your sprints realistically
- Know at a glance if something’s stuck or if you’re behind schedule
- Make sure your team is aligned with the timeline
- See clear ownership of bugs and features