Message sent!

Someone from our support team will contact you shortly.

Get a Quote

Your email *

Tell us why you're considering making a switch:

Schedule a demo

Your name *

Your email *

Number of team members *


Tell us why you're considering making a switch:


How to Create an Agile Project Management Plan

16 Apr 2019

Developing software always requires some sort of a plan to be in place. The very word "plan" is open for discussion in the project management world. In a traditional sense, planning is crucial for a project's success. On the other hand, in the Agile environment, planning is more of a guideline for the project's progress. That being said, let's have a look at how to create an Agile project management plan.

The perspective on plans in both methods

In order to clarify things further, we must first take a look at how a plan or plans are viewed from both traditional and Agile point of views. In traditional methods, planning is a vital component of any given project. A plan can encompass the entire project ranging from gathering information and creating documentation, development, testing, scheduling and establishing a release date.

The foundation for such a plan is that a project manager will be able to accurately predict how long it will take, how much it will cost and what it will take for the software to be developed and released in a pre-specified time frame. On the other hand, plans are viewed differently in the Agile methodology.

Plans in Agile are purely feature-based. In other words, Agile plans can project when the features will be developed without the focus on how. Simply put, you can have a really good guess about what will be delivered and when it will be delivered based on how much the teams can develop within a specific time frame, which is usually a single iteration.

agile plan

Information gathering

Every Agile project management plan begins with information. Information gathered from clients, developers, stakeholders and anyone else involved can help create a vision of what the project should look like. Furthermore, the vision itself includes "what" needs to be delivered, "who" should be involved and "how" will people work together to make the project successful.

This information and envisioning help create a project backlog that consists of both business and technical requirements, as well as help create a project roadmap, which is an overview of how the product will evolve overtime. Once the information is obtained, you can start planning the next phase.

Populating the backlog

Large user stories, also known as epics, can project a picture of how an end-product should look like. However, in order to get started on the project, you have to break down the epics into smaller user stories or individual features and requirements, and prioritize them to plan for iterations.

This is also known as populating the backlog. The essential thing here is that Agile teams will not try and plan out every little thing that will make up the backlog. Instead, they will keep them vague until the time comes to work on them (more on this later).

Estimating releases

As mentioned before, you can have a pretty good guess what will be delivered and when based on what your teams can deliver. Estimating releases, whether for a single iteration or for the entire products is a common practice in Agile projects. You have to have at least a rough estimate of when the iterations will be completed and when the project will be nearing its end.

You can make these estimations based on the previous work, i.e., previous projects. How long it took your team to develop a specific number of features within a single iteration on a similar project will probably be the same amount of time it will take them to do the same on the current project. This can help you estimate release dates more accurately.

Of course, all of this should be used for estimations only, not as plans that are set in stone.

Consult with your team

Once you have a general idea of what needs to be delivered and when, you can consult on your project roadmap with the rest of the team members. They can provide input on whether or not your roadmap is achievable or not. In the end, a project manager in an Agile environment doesn't own the plan. Instead, the team owns it in the fullest.

The main reason is that the teams are responsible for communicating with clients and deciding on which features should be developed in the next iteration, as well as the functionality required for that feature to be developed properly. After all, the teams are the people who will do all the work and they are, in fact, in the best position to decide on what needs to be done. Therefore, if the team members say your plan needs to be improved, then it's time to make the improvements.

planning with your team

Planning just in time

Perhaps the most important difference in planning projects the traditional vs the agile way is in how comprehensive they are and how long into the future they extend.

A good Agile project management plan will be done just in time and just enough. For instance, even the Product Backlog will not be too detailed for more than one or two Sprints in the future.

This is done so that as little time is wasted on making plans that will become obsolete anyway and act as hindrance more than anything else.

Closing Word

The agile approach does not preclude the team from making plans for their product. However, an agile project plan will be more about the big picture stuff, leaving the smaller, more direct plans to be made just in time and by the entire team.