a step by step guide to agile pm


Project management is not as simple as just creating a plan and executing it. There are many other things that you have to take into account: managing a team, communicating well, delivering a product, tracking progress, assess risks… But how do we combine all of that with agile? Is planning compatible with agile?

Here you will find a step by step guide so that you can project manage like a pro using agile. These are the steps I follow and that have been proven to work. Let’s get started!



If we’re building a new product, this is how we start working on it. First, we need to understand what is the problem we are trying to solve and the impact that it has on our customers. To do so, it’s important to empathize with the end user. Ideally, we should talk to them in order to understand their pain points and their needs. If we have troubles to empathize with a particular user, we use the Empathy Map.

Another good practice is to create personas and scenarios and keep them handy so that the whole team can have access to them easily. In agile, we design and develop always with the end user in mind so it’s a good idea to keep the personas in a place where the whole team has access to (I put them in a board in the office or in a shared folder if we are working remotely).


After we’ve defined the problem we need to make sure that we have a team that can help us to solve it. If you already have a team, we need to make sure they are right for this specific project. Ideally, we should work with a cross-functional team. If you don’t have a team or the one you have doesn’t have the right skills, it is worth to spend some time getting the right people on board.


We need to define what success looks like for your project. Otherwise, there won’t be a clear way to know whether we have achieved it. Success can be interpreted differently depending on who you are talking with so it is important that all stakeholders, clients, project managers and the team know the criteria that would make the project a success.


Once we have a team and we know what our user needs are, it’s time to brainstorm to find different solutions to their problems. It is very powerful to involve the whole team because each of them may come from different backgrounds and may have different ways to solve problems. We aim to be bold and not to go into the nitty-gritty of the solution.


I’m not talking about working software yet. A prototype can be done on paper or using a mock-up builder like Justinmind, Balsamiq or similar. The idea is to build a simple and low-fi prototype that we can show to your users in order to get feedback from them. As we haven’t started building yet, we can adapt and change the solution based on this feedback which is more cost-effective than doing it later on.

start a business image


Before we start working on our sprints, we need to do a few planning tasks. My approach to planning is iterative because in some projects there is a lot of uncertainty and things can always change so it’s important to be able to accommodate change even later on in the project.


The first thing we need to do is to write down what’s on scope and what’s on out of scope. As we’ve done some testing with our prototype it should be easier now to prioritize and decide what we are going to build. If prioritizing gets tricky, I use the MoSCoW technique.

A Project Scope Document can be created at this stage as a live document that can be updated during the project.


I make sure that each team member understands what’s required of them. But it is also important to know how they can help the team, if they need any resources to do their job that is currently missing and if there is anything getting in their way.

I usually document all these together with any dependencies.


The roadmap describes how the product is likely to grow across the next product releases. It’s a high-level overview of what the product would become and it focuses on goals more than on specific features. There are a variety of software out there that provide facilities for roadmap creation but it can also be created on an MS sheet.

In the roadmap, we will map out the major project milestones. It’s more of a strategic plan rather than a release plan.


It is a single list of everything needed in the product. It includes the epics and user stories that will have to be developed during the next sprints for specific releases.

This is more of a tactical tool and it describes features than the team has to implement. The Product Backlog is at the heart of agile/scrum and it should be revised often as priorities may change.


This is another tactical tool. It describes when the potentially shippable product will be released. A release can be formed of several sprints. If we have just started working with the team and we don’t know the amount of work that can be completed per sprint, we would need to make estimations and then adjust as we progress.


It’s imperative to think about what it could go wrong before it does and to have a backup plan. As a team, we should all work together to identify risks before we start building.

The team should consider:

  • What could slow down the progress or make us miss a deadline?
  • How quickly can we respond when something goes wrong?
  • Is there anything that we already feel anxious about?

I usually create a RAID Log at the start of the project that I use to manage risks constantly through the project.


We decide what would be the system for reporting and distributing information within the project for the different internal and external stakeholders.

  • Internal communications: We decide how often we will have our meetings and who will participate as well as how events will be communicated to the team.
  • External communications: We need to know what information will be provided to which stakeholders and when we will be meeting with them

discussing customers feedback



Depending on the project sprints normally take from 1 to 4 weeks. During this phase, I usually run the following scrum events if :

  • Sprint planning meeting – We decide what will be delivered during the next iteration. Always starting with the highest priorities.
  • Daily Standup – A 15 min meeting where the team inspects what was done yesterday, what will be done today and if there are any roadblocks.
  • Sprint Review – We demonstrate what has been developed during the sprint. Here we can get instant feedback from the client.
  • Retrospective – After the sprint review and before the next sprint planning, the team inspects how the last sprint went.

I use digital collaboration tools like Trello, ProdPad and Dropbox for files sharing and task tracking. This way everything is in one place and the team has access to the materials needed to get work done.


I keep track of what pieces of work are already completed, budget status and if there are any delays or issues that will prevent us from meeting our deadlines.

I like to send project status updates to my clients pretty often, many times daily so that they always know where things are at.


Agile is all about getting feedback and iterating. At the end of each sprint, we have a demo with our client to show the product advancements and new features. Ideally, we should be able to show it to end-users as well.

Depending on their feedback, the backlog may need to be groomed and some features may become high priority. It’s all about adapting and embracing change.

testing and feedback


Once the product is ready is time to launch it! Exciting times!

To close the project I make sure I get my client final approval. I also close the budget, make any outstanding payments and create final reports.

Another good practice is to have a post-mortem meeting with the team to share the lessons learned and also talk about any future iterations the product may require (if any).



If you are developing a new product in a highly uncertain environment, please take into account that milestones and forecasts are usually not very helpful because startups are too unpredictable.

The main focus for you should be to prove if your initial hypothesis is true. And for that, you will need to have real interaction with your customers. So get out of the building, ship often and iterate based on your customers’ feedback.

Tip: Often customers don’t know what they want, so don’t ask them! Observe and analyze what they do and what they say when they use your product.

If you are a startup I highly recommend you read The Lean Startup by Eric Ries.

Leave a Reply

Your email address will not be published. Required fields are marked *