Project Management in the Agile World

Summary

In this article I wanted to share the project management approach I developed over the years that was successful in managing agile projects and project teams that use Sprint planning. The key things you will see are how to define the project scope and manage changes to the scope and how to build a two level project plan where top level plan captures the structure and the resource needs of the project. Having the contribution of the full team is important in defining the scope, building the top level plan, and making revisions over time. After talking about the process, I also talk about the tools I use in this process.

Introduction

When your company decides to be agile, behavior of your customers change. I experienced all of the following, even in an early-stage startup where customer was internal, and we were building the alpha release of a single product.

When you are agile it is easier for customer participate in Sprints during execution. You may be asked to be flexible and take on new scope increases over time. You need a way to have this discussion with your customer transparently and plan accordingly.
You will be asked to complete multiple projects concurrently more frequently. You need transparency and flexibility in how you allocate resources across multiple projects with dynamic priorities.
You will continue to have turnkey projects with a large scope and timeline commitment. You need to have a plan that you can use to discuss it with your customer transparently to manage scope and timebox the project.

I this article I will share the project management approach that works within an agile organization, and extends to the whole project portfolio you may have at any given time.

The high level approach to project planning is as follows:

Define everything that needs to be done in a Work Breakdown Structure (WBS).
For every work item provide an effort estimate.
Build a rough plan that considers dependencies between tasks, assigns work items to specific team members and specific Sprints.
Share the plan with all related teams to be used in their Sprint planning.

Here are key decision criteria I used in developing the method I share.

Project plan needs to be flexible, scope may change, and even resources may increase or decrease during a big project. Cost of changing a plan should be low.
The whole team needs to have access to the project plan. Team may have a mix of Windows, Mac, Linux machines, and all the managers should be able to build and modify the plan.
The plan needs to capture details, and also provide a high level view. When discussing a plan with customers or the top level management within your company they should understand the big picture quickly.

First Step – Build the Work Breakdown Structure

The WBS is an established method for taking a project and hierarchically breaking it down to its parts. Having a clear top level view of a project drives predictability of its planning and execution. In many cases, delays in projects come from forgotten work items or ignored dependencies. Forgotten work items not only increase the resource usage, very frequently they also cause slips in delivery timeline.

An typical example for a forgotten work item is the documentation needed for Q/A or deployment. Normally this can be planned ahead and should not impact delivery timeline. In case it is raised as a missing item when you deliver code to Q/A or to deployment on target date, it is appended to your project plan even when you finished all development as planned.

It is important to build the WBS together with the teams at the beginning of a project. This can be done in a dedicated meeting. The team goes over the whole scope and builds the WBS. One can define the scope as software development, but I have a strong bias for covering the project completely, including testing and deployment.

The WBS must be comprehensive and should cover 100% of the scope to be planned. Some of the work item categories are as follows:

Requirements analysis and business design as needed
Technical design
User interaction points, screens, apps, messaging, IVR, etc.
External data or functional interfaces, databases, APIs, messaging pipes, data busses, data pipelines, logging, bulk data imports and exports
Administrative interfaces, application configuration, deployment configuration, etc.
Data history, metrics, and reporting changes.
Testing, ideally for every change in WBS. It is convenient to track testing under each relate work item to ensure it is included as scope changes over time.
Migration planning, and necessary migration work items.
Documentation updates and Training material updates

This list depends on the nature of application and the policies of the company. It may be simpler, or extended to include work categories like deployment.

Granularity of a Work Item in WBS

The WBS does not need to include a separate work item for every task you will have in your Sprints. It needs to have work items that cover all the tasks. For Sprint planning a work item can be one task or turn into 20 tasks. This breakdown is handled after the project planning, while Sprint backlogs are managed by Sprint teams.

WBS has a tree structure, and in my experience 2 or 3 level tree is usually sufficient to capture the needs of project planning. The level of detail we go into in WBS should not be high, otherwise making changes to scope and to plan becomes expensive and error prone. We need two things from every work item:

We need to be able to estimate the resources needed to complete a work item. Work items with children sum the resources of their children.
All leaf work items on the tree need to be assigned to a single individual.

The second item above can get objections. Sometimes there may be multiple candidates for a work item. I insist on assigning every work item to a specific individual during planning.

In my experience using resource pools in planning is complex and fragile. For example, consider that we need a full resource for a work item for the whole month of July and people may have planned vacations for that month. When you assign the task to a specific individual, and even when you forget about considering availability, the person will still look at his/her plan and point out the need to include the specific vacation plans. Modelling this at a resource pool level and mapping it to project planning is much more complicated, and for me not worth the effort.

Second Step – Estimate Effort and Assign Resources to Work Items

The targeted granularity of work items become really important once you move into planning. Before planning, two important things need to be done. One is effort estimation, and the second one is assigning resources. I strongly suggest doing both at the same time, because in software engineering the resource assigned to a work item may determine the effort needed to complete it. It is natural to prefer the people who are familiar with the topic and the technologies which reduces the effort. On the other hand people in high demand may be overbooked so you can assign work to people who are available for the planned period but may take longer to deliver.

There may be cases where you cannot estimate the effort accurately, for example you need to develop a new UI and it needs to be designed first. The developers may have a wide range for the effort depending on what UI was designed. In these cases, for the purpose of project plan you enter a specific effort estimate based on the experience of the team and expected complexity. Take a note that is visible everyone including to the customers that if the design they want turns out more complicated, the effort may increase and project timeline may be affected.

Third Step – Build Project Plan for Work Items

The last step in building the Project Plan is placing all the work items on timeline. Since we are in the agile world for software development, and everything is managed in terms of Sprints, I want to see a Sprint based project plan. To be specific, timeline is in terms of Sprints, If you have a 40 week plan with 2 week Sprints, the project plan needs 20 Sprints, that is 20 time slots. You don’t really need to go into details of what happens in each Sprint for a plan at this level, this way you can also keep you work item granularity larger than individual tasks.

In the plan, I propose there is a slot for every resource for every Sprint. The slot contains the work item(s) this resource is assigned. At the end of planning, you need to have 100% coverage of your work items in these slots. There can also be cases a work item with multiple children in WBS is planned as a single item over one or more Sprints.

There are basic steps you need to take in building the plan. One is to make sure resources assigned to work items in a single Sprint don’t exceed the total resource availability for that Sprint. The other one is of course work items that depend on each other need to be ordered accordingly. In cases where large dependent work items can be pipelined over Sprints this can be done.

Work Item Pipelining Example

In a realistic scenario with dependent and time consuming tasks, a project manager would like to shorten project the project timeline by pipelining dependent tasks. A common example can be the 3 work items for designing, developing, and testing a software module. Assuming each work item takes 3 sprints on its own, doing them sequentially would be 9 sprints. However agile development allows Sprint based partial delivery that may enable the dependent work item to start in the following Sprint.

We can start design in Sprint 1, and with the early results of design, we can start the development in Sprint 2, hand it over to testing in Sprint 3. In a total of 5 Sprints the work will finish instead of 9! Breaking a work item into Sprint based partial deliverables may increase the effort for work items. When we move from 3 to 4 Sprints for development and testing, the plan will take 6 Sprints instead of the original 9.

Design in Sprints 1, 2, 3,
Development starting Sprint 2 and finishing Sprint 5,
Testing starting Sprint 3 and finishing Sprint 6.

Once building and modifying a project plan is easy, managers gain the power to use benefits of agile methodology to make decisions on cost and delivery time.

Tracking the Project Plan

When you are working agile, plans become dynamic. You need to make changes to project scope and to the plan as you make progress in the project. As project budgets and priorities may change, your resource planning may change and also sprint based time allocation to specific projects may vary. You need the ability to review not just where you are according to the plan, but also how your plan changed over time.

Taking snapshots of the project plan periodically, and then having the ability to compare the snapshots with each other and with the latest plan is useful for a number of reasons:

You want to be able document the work items that were added to the project after project kickoff. New work items may be things like late coming regulatory compliance needs, new business needs, or scope that was said to be later defined in the project.
You want to document scope revisions that changed required effort for work items. When you work agile with your customer on the project details, changes can grow or shrink work item scope.
Your effort estimations may not be always accurate and you would need the ability to identify where estimations differed from actuals.
Your resource availability may have changed and you may need to identify execution plan changes beyond changes to WBS.

You need to have the ability to take snapshots of the project plan periodically or at project milestones and keep an archive of these for future reporting and analysis needs. It is best if these snapshots can make it easier to make comparison of the WBS’s, resource utilizations, etc.

Once you build a project plan that uses Sprints as the basic time unit, the managers can break the work items into tasks while building their backlog and plan their Sprints accordingly.

Tooling

In selecting a tool for project planning I have a few criteria

Tool must be supported on Windows, MacOS, and Linux. When the project teams become large and include teams like business/product analysts, multiple development teams, Q/A, deployment, also including contractors, platform variations are inevitable.
Tool must work comfortably at Sprint time unit level. As needed a work item may me scheduled across multiple Sprints.
It should be easy to do resource allocation at Sprint level. For example resource X is available 100% in Sprint 5 but only 50% in Sprints 6 and 7.

The basic assumption is that the work items used in project planning are from WBS and these are different from the tickets you have on software development board, and also different from the tasks uses for Sprint planning.

I have used a number of different project planning tools, including MSProject and popular addons for Jira, but at the end I use spreadsheets extensively. Both Microsoft 365 Excel and Google Sheets are flexible and capable to get the task done. Spreadsheets are my tool of choice.

WBS in a Spreadsheet

In creating a WBS, capturing the tree hierarchy is important. In a Spreadsheet I reserve first 5 colums to capture level 1 to level 5 (if ever needed) of the tree hierarchy. In my experience 3 levels are usually enough to capture details sufficient for Sprint based project plan. Further details don’t appear in WBS and handled by teams that take on the work item.

Next to each leaf work item would be resource assigned to the work item in a separate column, and the total effort needed to complete the work item. As stated above, every work item can be assigned to a single person, and the effort estimate is a decimal number for that person in terms of number of Sprints.

Project Plan in a Spreadsheet

There is a cell in the spreadsheet for every resource and for every Sprint. I place resources on separate columns where column header identifies the name of the resource, and every Sprint is a different row where the first Sprint of the project is the first row of the plan.

When placing work items into the cells, one needs to consider the dependencies between work items and utilization of the resource assigned to the work item. If certain resources are not fully available for the project in a certain Sprint, this can be written down as a note next to the Sprint line.

Once all work items are placed, we have our first version of the project plan. In the spreadsheet format I put the plan on the same sheet with the WBS, usually to the right of the WBS tree. This makes it easy to ensure work item dependencies are covered in the plan and, all work items are planned, and resource allocation is consistent.

Once a plan is made, I recommend naming the sheet with the date of the plan. Every time you need to modify the WBS, the plan or both, you can start a new sheet by copying the last sheet. This way at a later date you can compare versions of WBS and project plans. One other thing I do is never modifying the project plans on old sheets, but creating a new version of the plan below the last one. In my experience project plan revisions don’t happen frequently and plans don’t have very large number of rows, so it is possible to see previous plan and current plan on the same screen for quick review. This way an old sheet will have the old WBS and the plan (and previous plans) at that date, and a new sheet will have the latest WBS and a list of old plans with latest plan at the bottom.

How to Manage a Project Portfolio

Once you have a project plans with schedules and resource allocations, you can merge them together to manage a project portfolio. Sprint based schedule and resource utilization for a collection of projects will make it easy to see the big picture and make decisions. The most common issue in a project portfolio is heavily utilized resources that become critical resources. Having high level plans makes decisions easier.

You can ask for more resources/budget to increase the capacity of critical resources
You can assign other, underutilized resources to some project to take over the work of overutilized resources
You ask for prioritization of projects where lower priority ones are delayed for resource availability.

Of these, first two approaches are the ones I find more productive. In the third option, if you are identifying a project as low priority among others, there is a risk that such a project may be delayed even further because new high priority projects can appear in the coming months

Conclusion

In this article, I described a hierarchical project planning approach I use. At the top level you start by building a WBS. The you build a high level plan where time units are Sprints and all resources are named. This is a plan that can be used with internally as well as with the customers. At the second level plan, managers are entitled to divide up the work items into tasks and plan and execute them in their Sprints according to the project plan. The number of tasks in the Sprint plans may easily be 10 times more than the work items in the project plan. Two level structure makes the top level project plan more readable and understandable.

As new scope is added or effort estimates change in a project, the WBS and the project plan is updated to reflect the change. This also allows the project manager to have a meaningful discussion with the customer on how to move forward. Scope may be trimmed somewhere else to meet the deadlines, project delivery timeline may be modified, or if possible extra budget may be allocated for additional resources. Top level plan is usually sufficient for such discussions.

Using a spreadsheet in project planning is simple but effective. I used almost all the popular project planning software in the past. For broad accessability, and ability to handle frequent changes to projects, I went back to the spreadsheet. I gave up many things in using the spreadsheet, detailed reporting, native Gantt chart support, dependency diagrams, identify critical paths and calculating slack in schedules etc. It is possible to do these in a spreadsheet, but these were secondary for a broad adoption and execution of a plan. You can always take the plan and turn it into a plan in the project management tool of choice of your company or your customer as needed.

When the whole team and the customers see and understand the project plans, agility becomes a powerful tool for collaborative productivity increase.