Agile Mapping for PMBOK Knowledge Areas

In my previous blog post I wrote about the probable mapping between PMBOK Process Groups to Agile processes. PMBOK organizes the five project management process groups and the project management processes to nine project management knowledge areas. The project management institutes recommends that project managers have a good understanding of these knowledge area to deliver outstanding service to their customers.




PMBOK Knowledge Areas:

At the outset the PMBOK knowledge areas look more in tune with the water fall development. But true agile practitioners will see a a lot of overlap in the knowledge that they need to successfully manage a agile/scrum delivery in the PMBOK process. For example the PMBOK Integration Management  can be directly mapped in agile to
1. Release Planning
2. Backlog Grooming
3. Reviews and Retrospectives
4. Burndown Visibility
This kind of mapping I found becomes necessary when talking about agile development with Project Managers and Business Analysts who have been trained in the traditional methodologies. I have tried to create a mapping table between the PMBOK knowledge areas and agile for reference to agile practitioners to use in conversations with PMO folks.

You can see from the table that it misses the following PMBOK knowledge areas in the agile mapping

1. Procurement Managemet
2. Project Cost Management

These two are basically in my view enterprise level tasks and best left to the PMO. We can also give a fair amount of control over the Time Management to PMO for making the agile projects enterprise grade.

By showing the PMO and Business analyst that agile is not a renegade process and explining that agile artifacts and ceremonies are indeed easily mappable to PMBOK process groups and knowledge areas we can elevate agile acceptance in the enterprise.

Agile Mapping for PMBOK Process Groups

Most of the organizations that develop software products employ standard project management practices and expect their employees to follow those process in their daily work at the organizations. In many of the prodcut development efforts that I worked I have had a Project Manager trained in PMBOK practices help manage the project at the enterprise level.
When teams switch to Agile/SCRUM Product development there is a change in how things are done and many times it appears as if there is a conflict between the PMBOK practices and Agile methodology.




In reality this need not be the case, agile practices can easily fit into PMBOK constructs and help develop products in a faster,leaner way. Similarly PMBOK prctices which looks like they are more suited for Waterfall development can be adapted to Agile methodology easily if we undersatnd the mapping between the two. The mapping of PMBOK and Agile methodology can help getting Agile accepted by the enterprise without much difficulty.
PMBOK guide says Projects are accompolished through process and espouses major processes that needs to applied in every project some form of the other to successfully complete the project. These processes are aggregated into five groups defined as the Project Management Process Groups:

• Initating Process Group
• Planning Process Group
• Executing Process Group
• Monitoring and Controlling Process Group
• Closing Process Group.

An undelying concept of the interaction between the process groups is the Plan - Do - Check - Act cyle from the TQM pronciples by Deming which the Agile Practioners are familiar with.

With this concept behind the PMBOK Process groups it becomes very easy to map the Agile Process Flow to the PMBOK process group flow. Let us see how this plays out.

The PMBOK process groups are not alien to the Agile/Scrum process flow. This kind of mapping can be used as a starting point of the conversation between the Scrum product owner and Project Manager to identify how the Agile mode of working can co exist with the enterprise level PMBOK processes in the organization.

Agile Project Management - Capacity Planning

Capacity planning helps teams to commit to the right amount of work for the upcoming iteration.  The goal is to forecast future iteration/release capacities, a reasonable goal, but not really accurate because we do not know what the future holds so at the outset the forecast value is not the one that the capacity planning is focused on meeting. We should use capacity planning to find the following, on a given amount of capacity value what can I predict to accomplish with it.

Most of the time in Sprint planning we are more focused on velocity, a value that gives the value of amount of work done in a sprint which allows us to do target estimates with static team setup which is a must for agile teams as per agile manifesto.

Now let’s focus on the goal of planning future iterations.  For example our team wants to be prepared for 2 iterations into the future.  This would mean the team members would enter their capacity planning information into the future.

I am going to assume that you have given me the following for your team past sprint performance:

 Iteration N-2    Iteration N-1   Iteration N     Iteration N+1    Iteration N+2

Capacity (hrs)   100                  110                   100              120                   100

Estimate (pts)    13                    11                     10                 ?                        ?

N is the current iteration.

 From your past ratio of Estimate/Capacity I can determine a ratio that can then be used to calculate my target estimate.

 Ratio = (13+11+10)/(100 + 110 + 100) = .1096

Expected/Target Estimate

Iteration N+1 = (120)(.1096) =  13.5

Iteration N+2 = (100)(.1096) = 10.9

To summarize the key number for calculating target estimate is now Estimate/Capacity instead of Estimate/Person.