« Back to Planio Blog

Jory MacKay on January 11, 2018

Jory MacKay

Jory is a writer, content strategist and award-winning editor of the Unsplash Book. He contributes to Inc., Fast Company, Quartz, and more.

January 11, 2018 · 17 min read

How do companies like Microsoft and Google update every single one of the products in a week or two while other companies take years? The short answer is: Agile project management.

While teams following a “traditional” software development process (like Waterfall) will spend months or years building a product before showing users, Agile flips that process on its head.

Agile project management is a product philosophy that’s built on moving fast, releasing often, and learning from your actual users. And it works.

Research from the Project management institute found that Agile organizations are more likely to finish projects on time (65% vs. 40%) and hit all their goals (75% vs. 56%) when compared to non-Agile teams. Agile companies even grew their revenue 37% faster!

Let’s repeat that one more time before we dive in: Agile teams build products faster, hit their goals more often, and make more money. So why wouldn’t you want to bring Agile project management to your team?

Jump to a section:

In this guide, we’re going to help guide you through the core principles of Agile, help you evaluate if it’s right for your team, and then teach you how to get up and running with our 7-step Agile project management implementation plan. We have even included a Free Agile Checklist to help you identify the Agile resources and processes you need and help guide you through the transition.

What is Agile? And how does it work in project management?

Agile is a development process that takes an iterative approach to building software. Teams use a number of Agile methodologies to plan releases and then work in time-blocked “sprints” to continuously push out new software and learn from customer feedback.

(We’ll get into the specific Agile methodologies later or you can jump there now!

It’s this tight “feedback loop” between customers and the developers that allows Agile teams to increase their development speed, collaborate better, and react quickly to customer needs and market changes.

Yet while Agile has become the standard for almost every major software company from Apple to Facebook to Spotify, this wasn’t always the case.

Until the last few decades, most projects were run on what’s known as the Waterfall (or Traditional) method of development. In the Waterfall method, teams plan out the entire development process first and then work through it sequentially before releasing it to users.

This means companies were investing a huge amount of time, resources, and money into something they didn’t even know would be a success.

Be design, the waterfall method relies on predictability and sequence. But what most software developers started to crave was a more flexible project management method that included space for errors, bugs, setbacks, market changes, and feedback from real users.

So, in 2001, a group of 17 individuals came together to create an “alternative to documentation driven, heavyweight software development processes.”

They called it the Agile Manifesto.

The 4 core principles of running an Agile project

At its core, Agile project management isn’t so much a methodology as a philosophy.

This means that while there are many different ways to implement Agile, they all share a few core beliefs that clearly differentiate them from the Waterfall method:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

This doesn’t mean you should ignore the tools, documentation, and plans you’ve worked so hard to develop. But rather that the core focus of Agile project management should be on people, prototypes, collaboration, and iteration.

While these principles give you a good high-level view into the Agile mindset, they’re still a bit vague. That’s why the original Agile founders also released a list of 12 guiding principles for running an Agile project:

1. The highest priority is to satisfy the customer through early and continuous delivery
2. Welcome changing requirements, even late in development
3. Deliver working software frequently, from a couple of weeks to a couple of months
4. Stakeholders and developers must collaborate on a daily basis
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. Face-to-face meetings are deemed the most efficient and effective format for project success
7. A final working product is the ultimate measure of progress
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility
10. Simplicity, maximizing the work not done, is an essential element
11. The best architectures, requirements, and designs emerge from self-organizing teams
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

If you think of software development today, Agile is a direct response to sky-high user expectations.

The core focus of Agile project management should be on people, prototypes, collaboration, and iteration.

Users don’t care about documentation, they care about working software. They don’t care about your long-term plan, they want something now. If you’ve released a bug, they expect it to be fixed now–not in a few months–or else they’ll find another option.

We’ve all become very needy consumers, and Agile is a fantastic way to make sure the user’s needs are put front and center whenever you’re developing new software. But how do you put it into practice?

The core components of Agile: Sprints, standups, user stories, and more

Agile as a concept isn’t that hard to grasp. But like any tool or method, Agile has its own quirks and nuances you need to understand if you’re truly going to master it.

Before we dive into the specifics of implementing Agile project management, let’s go over the core components you’ll be using.

User stories

User stories are the backbone of planning out an Agile project. Simply put, a user story is a short, simple feature description told from the perspective of your users.

In most cases, they take the form of:

“As a [type of user] I want [some particular feature] so that [some benefit] is received.”

This format helps you get specific about what needs to be built and why so you can more accurately estimate the time involved to actually make it!

Check out our in-depth Guide to User Story Mapping for more!

Sprints

Sprints are short cycles of development where you work towards a release. A typical sprint should take about 1–4 weeks and needs to finish with some usable piece of software being shipped.

The goal is to keep these sprints the same length throughout the project so it’s easier to plan future work, adjust your goals, and not get bogged down.

There’s a lot that goes into planning and running sprints, which is why we put together this in-depth Sprint Planning guide.

Meetings (stand-ups, planning, retrospectives, etc…)

In Agile, teams self-organize and decide what should be included in sprints. This means that regular meetings are a huge component of keeping your team on track.

The core meetings you should think about are:

• Daily standups (or “scrums”): These are quick daily meetings where everyone talks through what they’re working on. It helps you stay informed and focused on hitting the sprint goals.
• Sprint planning: This is a longer meeting at the start of a sprint where the Agile team decides what work should be included.
• Sprint retrospective: At the end of a sprint, the team comes together to discuss what was completed, what worked, and how you can improve moving forward.

Agile board

Agile projects move quickly and you need a tool to keep you organized.

An Agile board can be as low-tech as a whiteboard with sticky notes showing the current sprint’s user stories and progress. However, there are tons of amazing tools out there that can take your Agile team to the next level.

For example, Planio comes standard with an Agile board that you can use to organize projects and quickly see what the progress is of every task in your current sprint.

Using Planio, you can organize your entire product backlog and then assign tasks to sprints. Every task includes everything you need to move forward including details, priority, assignee, associated files and more.

You can even use the built-in time tracker to see if you’re accurately estimating how long a task should take to complete. (This is amazing for future sprint planning!)

Product backlog

As requests, user feedback, and new ideas come in, you’ll end up with a ton of potential features and projects to take on. These live in your product backlog until you’re ready to add them to a sprint.

The backlog can consist of features, bug fixes, non-functional requirements—pretty much anything that needs to be done in order to deliver working software. However, the product backlog is more than just a storing facility. It’s an important piece of the Agile puzzle that needs to be regularly updated and “groomed.”

Taking care of the project backlog is a major part of your role as an Agile project manager.

Team Roles

Finally, Agile project management brings in a couple of new team roles that you’re probably a bit unfamiliar with. While each Agile methodology treats team members a bit differently, the common roles you should know include:

1. Scrum Master: The Scrum Master helps ensure that each sprint stays on track by monitoring progress, facilitating meetings, and helping remove roadblocks. They’re also the team’s advocate and help communicate with stakeholders.
2. Project owner: The project owner helps define the goals of each sprint, manages the backlog, and represents the voice of the user to the team. This could be you (as the project manager) or someone else.
3. Team members: The development team does the work decided on for each sprint. Agile teams are self-organizing, meaning they decide how best to accomplish their work rather than get directed by someone outside the team.
4. Stakeholders: Every project has stakeholders–people who are impacted by the outcome of a project. In Agile, stakeholders are purely informational, as in they shouldn’t dictate how a project is run. For more info, read our guide on What is a Stakeholder in Project Management?

Getting started with Agile Project Management: A 7-step Agile implementation plan for technical teams

Now that you understand the philosophy and core elements of Agile project management, let’s dig into how to actually implement Agile on your team!

Switching to an Agile organization is a big move. And especially as a project manager, it can feel a bit daunting.

Agile promotes self-organizing teams, changing plans on the fly, and a ton of collaboration between the development team and stakeholders–all elements that make most project managers cringe.

But while Agile removes some of the structure you’re used to, it puts a different level of importance on project management.

Agile is all about rhythm. When you’ve got multiple, interdependent cycles of planning and delivery going on, your teams need to be in sync more than anything else. As a project manager or team leader, it’s your job to have that view from 30,000 feet up to make sure everyone is working together smoothly.

Agile is all about rhythm. When you’ve got multiple cycles of planning going on, your teams need to be in sync.

Here is our 7-step plan for implementing Agile project management:

Step 1: Set your project vision and scope with a planning meeting

What is it?

At the beginning of a new Agile project, you need to define a clear business need that your project is addressing. In more simple terms: what is the end goal of this Agile project and how will you achieve it?

An Agile strategy meeting covers big picture ideas but it also needs to be realistic. You can start to think about the scope of work, but remember that Agile projects need to be flexible and adapt to feedback.

To keep your planning meeting focused, try using the Elevator Pitch method:

• For: (Our Target Customer)
• Who: (Statement of the Need)
• The: (Product Name) is a (Product Category)
• That: (Key Product Benefit, Compelling Reason to Buy and/or Use)
• Unlike: (Primary Competitive Alternative)
• Our Product: (Final Statement of Primary Differentiation)

Who should be there?

The Agile planning meeting is where you get buy-in on your project. Try to include relevant stakeholders as well as the product owner and key members of the product team.

When does it happen?

A planning meeting should happen before the project starts. Or, if you’re working on a project continuously, plan a major strategy meeting annually to ensure your mission is still valid.

How long should it take?

The length of time an Agile planning meeting should take is totally subjective. However, depending on the complexity of the project, most can take anywhere from 4–16 hours (just not in a row!)

Step 2: Build out your product roadmap

What is it?

With your strategy in place, it’s time for the product owner to translate that vision into a product roadmap. This is a high-level view of the requirements, updated user stories, and a loose timeframe of how it will all get completed.

The ‘loose’ part here is important. You’re not spending days or weeks planning out every step, but simply identifying, prioritizing, and roughly estimating the time and effort each piece of your product will take on the way to making a usable product.

So, what does this look like for an Agile project? Product Management expert Roman Pichler suggests working with a goal-oriented product roadmap, which is sometimes also referred to as theme-based:

“Goal-oriented roadmaps focus on goals, objectives, and outcomes like acquiring customers, increasing engagement, and removing technical debt. Features still exist, but they are derived from the goals and should be used sparingly. Use no more than three to five features per goal, as a rule of thumb.”

For each of these goals, you want to include 5 key pieces of information: Date, Name, Goal, Features, and Metrics

Who should be there?

The product roadmap is the responsibility of the product owner but should include input from any other stakeholders in the project—think marketing, sales, support, and development team reps.

When does it happen?

The product roadmap needs to be in place before you start planning out sprints, so it’s best to move into creating it directly after your strategy meeting.

How long should it take?

Like all things in Agile project management, you want to move quickly rather than dwell on early-stage planning. However, your roadmap is a literal map from your mission to your MVP and should take as long as it does to feel confident that you’ve covered all the applicable goals.

Agile planning is a skill on its own.

Step 3: Create a release plan

What is it?

Agile project management isn’t is built around short-term sprints with the goal of regularly and consistently releasing usable software.

After you have a high-level roadmap in place, the product owner then creates a high-level timetable for each release.

Because Agile projects will have multiple releases, you’ll want to prioritize the features needed to get you to launch first. For example, if your project kicked off in November, you might set your MVP launch for early February, with a high-priority feature release the following May.

This all depends on the complexity of your project and the lengths of your “sprints”—the periods of work dedicated to each goal (which we’ll get into next!). A typical release includes 3–5 of these sprints.

Who should be there?

A release plan is like rallying the troops. The product owner, project managers, Scrum Master, and all team members should be present.

When does it happen?

At a minimum, your release plans should be created on the first day of any new release and reviewed at least every quarter.

How long should it take?

Be realistic about how long a release will take, but don’t let that slow you down. A typical release planning session should take around 4–8 hours.

Step 4: Sprint planning

What is it?

It’s time to move from the macro to the micro view. Together with the product owner, the development team plans “sprints”—short cycles of development in which specific tasks and goals will be carried out.

At the beginning of a sprint cycle, you and your team will create a list of backlog items you think you can complete in that timeframe that will allow you to create functional software. Then, it’s as simple as using one of the Agile methodologies to work through them (which we’ll cover more in-depth below).

Who should be there?

Sprint planning in Agile is done by the product team but should include input and guidance from the product owner, project managers, and scrum master. However, ultimately it’s up to the team to decide what should (and can) get done in a sprint.

When does it happen?

Sprint planning takes place at the start of each sprint cycle. For example, if you’re doing weekly sprints, you’ll do a planning session every Monday (or whatever day of the week you choose to start on).

How long should it take?

Sprint planning sets the tone for the cycle. So while you don’t want to spend too much time at this stage, it could realistically take you 2–4 hours. But once you’ve planned your sprint you’re quite literally off to the races.

Step 5: Keep your team on track with daily standups

Agile projects move quickly. And so it’s necessary that you have regular moments to check in and make sure there aren’t roadblocks getting in the way. These are called “stand-ups” in Agile-speak.

A standup is a daily, 10–15-minute meeting where your team comes together to discuss three things:

• What did you complete yesterday?
• What are you working on today?
• Are there any roadblocks getting in the way?

While this might seem like an annoyance to some of your team, these meetings are essential for fostering the kind of communication that drives Agile project management. Agile depends on reacting quickly to issues and voicing them in a public space is a powerful way to foster cross-team collaboration.

Step 6: Sprint reviews

What is it?

Each sprint cycle ends with a functioning piece of software getting shipped. And while this is a huge milestone to celebrate, it’s also an opportunity to review what was done and show this off to people on your team and any key stakeholders. Think of it as Agile show-and-tell.

Sprint reviews should cover the more practical aspects of the sprint. Check your initial plan and make sure all requirements were met according to your definition of done.

As the product owner, it’s your choice to accept or refuse certain functionalities. If something went wrong, ask why? How can you adjust the next sprint so your team can hit their targets? Agile is all about continuous learning and iterations, and this means on your processes as well as your product.

Who should be there?

The sprint review involves everyone who worked on and is impacted by the release. This means you should include your entire team as well as any key stakeholders.

When does it happen?

The sprint review takes place at the end of each sprint.

How long should it take?

Just say no to powerpoints and feature dissertations. The sprint review should only take an hour or two max.

Step 7: Decide what to focus on next in your sprint retrospective

What is it?

One of the core principles of Agile project management is that it’s sustainable. This means you should be ready to start on the next sprint as soon as the previous one ends.

To make sure you’re actually learning from each release (and not just moving forward blindly), you need to dig in with a sprint retrospective.

After you show off the release, a retrospective is a moment to think back on the process of the previous sprint.

Did everything go as planned? Was the workload manageable? Where could you improve your process or planning? Did you learn something during the sprint that changes your initial timeline or vision for the project?

Don’t simply plan, but also take this time to discuss how the previous sprint went and how you could improve in your next one.

Who should be there?

The retrospective is a natural extension of the review, and so while your stakeholders can leave, the rest of the team should be involved and giving their insights.

When does it happen?

It makes the most sense for your sprint retrospective to happen right after your sprint review.

How long should it take?

Again, keep it short and sweet. An hour or two max is probably all you’ll need to debrief and plan for the next brief.

What happens after the sprint retrospective?

By the end of the sprint retrospective, your team should have a list of imporvements and changes you can implement in your next sprint. And then the sprint process starts over!

Bring your learnings into the next sprint planning session and keep shipping functional software.

Getting started with an Agile workflow: How to pick the Agile methodology that’s right for your team

As we said earlier, Agile is more of a set of philosophies and principles rather than a perscriptive set of rules. As such, you can apply Agile principles in a number of different ways depending on how your team best works together.

These are called Agile methdologies. And while they’re pretty similar, they have their own unique practices, terminilogies, and tactics.

Let’s take a look at the top 3 most popular Agile methodologies and break down how they’re different:

Agile project management with Scrum

Scrum is probably the most well-known Agile methodology thanks to its simplicity, proven productivity, and ability to act as a catch-all framework for the various practices promoted by other Agile methodologies.

Like other Agile methodologies, Scrum relies on a set of time-bound sprints. However, Scrum is a bit more perscriptive on how you structure your sprints. Each Scrum sprint features four “ceremonies” that help your team move forward.

1. Sprint planning: A team meeting to decide what to include in the current sprint. Once the team has decided on what to include in the sprint nothing else can be added except by the team.
2. Sprint demo: A sharing meeting where the team shows off what they’ve shipped.
3. Daily Standup: Regular 10–15 meetings to sync up and talk about progreess and roadblocks.
4. Retrospective: A review of the results of the previous sprint to tweak your process.

Along with these ceremonies, teams will use a dedicated “Scrum board” that mirrors the process. During the sprint planning meeting, the team will move any active issues to the board.

As they work through them, the issues will move through the workflow from To Do to In Progress, Code Review, and Done (or however your team chooses to organize their board). The Scrum board is a powerful tool for adding transparency to your project management process.

Kanban

Like Scrum, Kanban is an Agile methodology built around continual delivery, while keeping things simple and not overburdening the development team. However, rather than use tightly time-bound sprints, Kanban teams organize around a limited number of “work in progress” tasks and can release at any time when they’re ready.

There are a few other core principles that help differentiate Kanban from Scrum:

1. Visualize your workflow on a ‘board’
While the Scrum board is a nice-to-have, Kanban relies on a visual board to keep all your Sprint’s tasks visibile and show progress. Kanban boards are also great tools for helping project managers manage resources and set priorities.

2. Keep your work-in-progress (WIP) limited
Like in Scrum where the backlog is defined before your sprint and nothing can be added (except by the team), Kanban sets a limit on the tasks that can be added to the WIP board. However, in most cases, Kanban teams don’t have a dedicated product backlog, but rather keep those tasks in a “to do” column on their board.

3. Release when ready
Kanban teams aren’t stuck to the rigid schedule of Scrum ceremonies and sprints. Instead, they can release whenever they work through enough WIP tasks. This adds extra flexibility, but also means you need to build in your own struture to not let releases take too long.

Extreme Programming (XP)

Extreme Programming (XP) isn’t extreme in the Mountain Dew sense, but it is a bit of a departure from the other methodologies we’ve discussed.

XP is a more disciplined approach to Agile project management that involves high customer involvement, rapid feedback loops, continuous testing and planning, and close teamwork to deliver working software quickly. To give you an idea, a typical XP Sprint lasts only 1–3 weeks.

The original XP ‘recipe’ described by software engineer Kent Beck, was based around 4 values—simplicity, communication, feedback, and courage—with 12 supporting practices. It’s definitely more complex than other methodologies and looks something like this in practice:

In XP, there are tight feedback loops where the “customer” works closely with the team to define and prioritize granular goals called “User Stories”. The team then estimates, prioritizes, and plans the delivery of these stories, getting more feedback from the customer until it’s ready for release.

How to know if Agile project management is right for your team (and why it might not be)

Agile is used by teams at pretty much every major software and product company in the world. But it’s important to remember that it’s not the only software development process out there.

Agile might be a big departure from how your company or your teammates are used to working. It means moving quickly, which means not everything will be spelled out or planned beforehand. Therefore, you need to know whether or not your environment can handle this kind of change.

Shiny new object syndrome and Agile project management don’t mix.

So before you go all-in on Agile, there are 5 questions you need to honestly answer:

1. Are you willing to start a project without knowing where you’ll end up?

You know that saying ‘fail fast?’ It refers to Agile project management. With Agile, you’re moving quickly and continually testing with real users. Which can be stressful if you’re a control freak.

Before you adopt Agile, ask yourself how comfortable you are with putting out a less-than-finished version of your product for users to test? Do you feel good about launching an MVP (Minimum Viable Product) or do you think your project needs to be fully baked before it can see the light of day?

2. How risk-averse are you?

Like we said before, Agile is all about continuously deploying and learning from your mistakes. This means you’re potentially taking on a higher level of risk than you would if you went with a more traditional project management style.

Is your culture a fly-by-the-seat-of-your-pants startup where risk is your middle name? Or are you standing on the precipice of failure and need to make sure everything goes perfectly?

3. How flexible is your team?

In Agile project management, you work with your customers to make the product better. But this doesn’t always fly with designers, developers, and makers of all kinds with an ego (i.e. all of us). Ask yourself if your key players can put their ego aside and adjust their efforts and ideas based on customer needs.

4. How strict is your company hierarchy?

One of the key principles of Agile is not only to work with your users but that developers will have access to key stakeholders on a daily basis. For some companies, this is a stretch. What is your culture like? Is there a hard set hierarchy in place or will those at the time gladly be a part of the development process?

5. How do you measure progress? And success?

Shiny new object syndrome and Agile don’t mix. Agile project management is all about working to continuously refine your processes and better your product.

If you’re more likely to just run off after the next exciting idea and leave the last one to flounder, you’re not going to get the best results that Agile has to offer. Take a minute to look at how you define success as a company. Are you looking for the big win? Or can you see that small, steady steps get you closer to your end goal?

The final piece of the Agile project management puzzle

Congratulations! You now should have a clear understanding of what Agile project management looks like and a few of the powerful ways you can use it on your own teams.

However, there is one last piece of the puzzle. With all of this information, organization, and prioritization happening, you need a proper project management tool to keep your Agile project on course.

The best project management tools addresses three pain points common to the Agile project management process:

• Reporting and metrics: Things like time tracking and projection, easy-to-understand progress reports for stakeholders, quality assurance, and a big picture look at progress
• Communication: The ability to keep everyone on track with updates to local and distributed teams, shared task lists, feedback, and assignments
• Project assessment: Functionality around identifying and remedying obstacles or bottlenecks, evaluating performance, and making sure financials are under control

While there are many tools that can help you with these, we’ve put together a guide on how to go Agile using Planio. If you’re moving your team over to Agile, we’d suggest giving it a read and trying out Planio for yourself!