How to run an agile project

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


Agile is a process that takes an iterative approach. Teams plan releases and then work in time-blocked “sprints” to continuously push out new software and learn from customer feedback to make constant improvements.

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 increased their revenue 37% faster!


“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?”


The first step in figuring out how to run an Agile project is to select your project framework. Scrum, Kanban, and Lean are popular Agile frameworks for organizing and running a project. Here is our 7-step plan for implementing Agile project management:


Step 1: Set your project vision and scope of work

At the beginning of a new Agile project, you need to define a clear business, what is the end goal of this Agile project and how will you achieve it? You can start to think about the scope of work, but remember that Agile projects need to be flexible and adapt to feedback.


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 are 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 make a usable product.


Step 3: Create a release plan

Agile project management is not built around short-term sprints with the goal of regularly and consistently releasing usable software. For example, if your project kicked off in January, you might set your MVP launch for early March, with a high-priority feature release the following June. After you have a high-level roadmap in place, the product owner then creates a high-level timetable for each release.


Step 4: Sprint planning

At the beginning of a sprint cycle, you and your team will create a list of backlog items you think you can complete within 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.


Step 5: Keep your team on track with daily stand-ups

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 lingo. A stand-up 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 members 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

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.


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 is 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?


Take this time to discuss how the previous sprint went and how you could improve in your next one.

If you wish more info about this topic, in this post you´ll learn about ppm process optimization in order to aligning portfolio’s projects with the strategic objectives of the organization.