Agile Project Management – Extending PMBOK

I have long held the belief that agile is only a part and a subset of the wider topic of project management.  I feel there are various aspects of project management that aren’t particularly covered by any of the most popular agile methods, or at least not by Scrum and XP (Extreme Programming).

Therefore I have always been keen to highlight the importance of project management beyond what is provided for by agile methods, and equally keen to help project managers understand where agile methods fit in to what they already know.

In the PMI’s PMBOK (Project Management Body of Knowledge), agile is not specifically mentioned, however PMBOK tends to describe what a project manager should be managing, and not much about how to manage it.  Arguably, agile methods tend to focus a little more on how.

Although agile and traditional project management methods place a completely different emphasis on different parts of the project lifecycle (eg waterfall/PRINCE2 puts a heavy emphasis on the planning phase, whereas agile does not), it is somewhat possible to augment PMBOK with agile methods, as they are largely complimentary.

I hope that one day this will actually happen as an official and global standard, but in the meantime I thought I’d have a go at expanding on PMBOK, and in the style of PMBOK, to give my view about where agile fits in with the wider discipline of project management as a whole.

PMBOK highlights 5 distinct phases that are typical in many projects:

  • Initiating
  • Planning
  • Executing
  • Monitoring and Controlling
  • Closing

I think the same phases can be and usually are applied to agile projects, but as I mentioned earlier, the emphasis and detail within the phases would change accordingly, and some of the language would also change too.

Because of the iterative nature of agile methods, all of these phases take place firstly at the project level, initially only at a high level, and then again in more detail within each iteration or ‘Sprint’ (Sprint is the name given to an iteration in the Scrum agile methodology).

In PMBOK, under the Executing phase of a project, there is one particular process labelled 3.5.1 ‘Direct and Manage Project Execution’.  PMBOK says this is the process of performing the work defined in the plan, but leaves more or less everything else to the project manager’s imagination.

Of course there are sections in PMBOK about managing scope, managing resources, managing finances, managing the schedule, etc, but PMBOK tends to cover what should be done and doesn’t usually explain how.

So the first extension to PMBOK that I would write for agile project management would be to drill down on 3.5.1 ‘Direct and Manage Project Execution’ to cover managing iterations within an agile project.  I have done that below, in the same style and using similar language to PMBOK, and also retaining the PMBOK numbering system.

Here it is…

3.5.1    Direct and Manage Project Execution

Direct and Manage Project Execution is the process of delivering the features defined in the ‘Product Backlog’.  In agile projects, the work is performed in short, fixed-length iterations.  Each iteration has 4 key processes, reflecting 4 of the phases of a typical project:

  • Plan Iteration (Sprint Planning)
  • Execute Iteration (Sprint)
  • Monitor & Control Iteration (Manage Sprint)
  • Close Iteration (Sprint Review)    Plan Iteration (Sprint Planning)

Plan Iteration (Sprint Planning) is the process of discussing what can be delivered in the next iteration, clarifying requirements for selected User Stories’, identifying tasks and estimating the effort, and committing to the work.


Tools & Techniques


.1   Product Backlog (Prioritised)

.2   Velocity Achieved Previously

.3   User Stories (Draft)

.4   Team Members’ Availability


.1  Sprint Planning Meeting

.2  Estimating in Points (Fibonacci)

.3  Planning Poker

.1   Sprint Goals

.2   Sprint Backlog

.3   User Stories Selected

.4   Task Breakdown and Estimates

.5   Team’s Commitment

.6   Cards on Whiteboard    Execute Iteration (Sprint)

Execute Iteration (Sprint) is the process of producing working software as planned for the current iteration.


Tools & Techniques


.1   Selected User Stories (represented by
Cards on Whiteboard).2   Task Breakdown
.1  Collaboration

.2  Test Driven Development

.3  Automated Testing

.4  Continuous Integration or Daily Build

.5  Test Early & Often

.6  Pair Programming

.7  Refactoring


.1   Working Software for Selected User Stories

.2   Test Confirmations

.3   Automated Tests

.4   Any Related Documentation    Monitor and Control Iteration (Manage Sprint)

Monitor and Control Iteration (Manage Sprint) is the process of tracking work in progress and assisting successful delivery.


Tools & Techniques


.1   Work Completed Yesterday

.2   Work Planned Today

.3   Impediments Affecting Progress

.4   Working Software for User Stories Completed So Far

.1  Cards on Whiteboard

.2  Daily Scrum/Standup

.3  Daily Burndown or Burnup Chart

.4  Review Product Frequently / Active User Involvement

.5  Address Impediments

.6  Definition of Done


.1   Final Burndown or Burnup Chart

.2   Velocity Achieved    Close Iteration (Sprint Review)

Close Iteration (Sprint Review) is the process of reviewing work completed in the current iteration, reviewing progress against the overall plan, reflecting on how the iteration went, and deciding how to improve in the next iteration.


Tools & Techniques


.1   Final Burndown or Burnup Chart

.2   Velocity Achieved

.3   Working Software for Completed User Stories

.4   Feedback from Team


.1  Sprint Review Meeting

.2  Sprint Retrospective Meeting


.1   Demo of Completed User Stories

.2   Updated Product Backlog

.3   Retrospective Actions

.4   Updated Velocity Graph

.5   Sprint Report


These processes are repeated for each iteration until the project’s objectives are achieved, or until it is decided that the objectives are no longer worth pursuing.

If you think I’ve missed anything important, have got anything in the wrong place, or just want to make comments, please do and I will refine this idea further and publish an update with your input.


13 Responses to “Agile Project Management – Extending PMBOK”

  1. Danerisms says:


    I think there is a key element missing here. The section is labeled “direct and manage” but if someone was to do this in agile the team dynamic would be stressed and would not allow the team to reach their full potential.

    PMI implies that resources (not team members in PMI) are very good at doing their specific task, but not so good at any of the other things such as communication to other team members. Therefore, they need some (project manager) to direct and manage their work. Think of it as building a house. The electrician is good at the electrical and can manage that part of the building, but without a project manager, there would be no one to tell the drywallers that they could put up drywall.

    Agile depends on the team members taking up a large portion of the direct and manage, leaving the project manager to focus more on roadblocks, release planning, and process improvement functions.

    I have seen first hand how assigning a strong project manager to an agile project as either a scrum master or an overall project manager can essentially break agile before it starts. A strong project manager won’t allow the amount of unknowns that are an accepted approach in agile. They will look to establish a risk plan for the entire project and work to mitigate as many of those risks as possible. Things like poorly defined scope will show up in this risk plan.

    I agree the PMBOK can include agile addendum to clarify a few of these items and I very much agree with the inputs in outputs noted above.

    Perhaps the first place to start on the PMBOK is to define a new section on People Management. Once the project manager accepts the team dynamic, there is not a section called “direct and manage project execution” but rather “support and assist sprint execution”.

  2. Dave says:

    I believe that PMI already has an Agile SIG (Special Interest Group) dedicated to exploring this topic. Try this:

  3. Peter Green says:

    Rather than use the term “Cards on Whiteboard”, which is a very specific instance that is common but by no means universal, I would use the term Sprint Backlog.

  4. Peter Green says:

    Daily Burndown should probably read Sprint Burndown, or Iteration Burndown, correct? I don’t think I’ve ever heard it referred to as daily, though it is updated daily.

  5. Kelly Waters says:

    Hi ‘Danerisms’. I kind of agree with your sentiment, because “Direct and Manage” does sound a bit autocratic. On the other hand I can’t help feeling that even the most self-organising agile teams also need direction and agile projects still need managing. So I think that technically it’s still correct and appropriate for agile projects, although something like “Lead and Support Project Execution” would feel more in the spirit of agile.

    Unfortunately I can’t find it now, but I recently ready somewhere that PMBOK will be introducing a section on people skills in the next edition. I think that’s a very good idea. I believe the people skills needed by a project manager are similar for any method of project management, agile or not, but I believe the style of management and leadership is very different, so I hope it emphasises leadership more than it emphasises control…


  6. Dave Gordon says:

    Great work, Kelly! However, for a practical standpoint, I think I’d rather see an Agile Extension to the PMBOK, published like the current Construction and Government extensions. There are already too many (probably legitimate) complaints that the PMBOK is becoming too IT-centric; better to keep Agile compartmentalized.

  7. Kirk Bryde says:

    Kelly, I agree with the comments of Danerisms. Essentially, the entire team takes joint responsibility to “manage the project”, rather than solely the PM. To be more blunt than Danerisms, it’s insulting for a PM to try to “manage” the work of an Agile team member, as the team member should (typically) have a better handle on the work and have equal commitment (to the PM and all other team members) to complete it on time.

    I also think that you should mention the release cycle, which should occur every 1-4 months. Any Agile team should release their software to their customer at least that often. Even though each iteration is technically shippable, in practice it’s often not.

    If you include the release cycle, then your last paragraph: “These processes are repeated for each iteration until the project’s objectives are achieved, or until it is decided that the objectives are no longer worth pursuing.” won’t sound so open-ended.

    I think the important point to make here is that Agile teams don’t miss release deadlines. Instead, come hell or high water, they do whatever must be done (sometimes cutting scope) to deliver on a fixed schedule (every 1-4 months). Since the schedule is fixed, release dates can be set as part of each Release Plan – at the start of each release cycle. This is much more comforting to stakeholders and customers than saying that you just keep going until you’ve either met scope or can the project.

    Kirk Bryde, CSM, CSP, PMP

  8. Kelly Waters says:

    Hi Kirk. Thanks for taking the time to share your comments, it’s always very interesting to hear different perspectives.

    I agree the whole team has to take responsibility, not solely the PM, but part of the PM’s role is certainly to help unify the team and in that way I think they are ‘directing and managing’. Ideally they would do that in a soft, collaborative, democratic, consultative, empowering way, not autocratic, dictatorial and controlling.

    Your comments about the release cycle are interesting, because I think the release cycle exists completely independently to sprints or iterations. I think the length of the release cycle completely depends on your context and, whereas sprints are fixed, the release cycle should vary based on whatever is necessary. For web site changes, we might release multiple times throughout a single two week sprint. For a ground-up build of a back-end system, even every 1-4 months might be challenging in terms of being able to deliver a full working system that has enough value to the users. So I totally agree that there should be a release plan (or ‘roadmap’) sitting over the iterations to give the team purpose across multiple sprints, and to give the business owners visibility of the bigger picture, and I certainly believe that the release cycle should generally be as short as practically possible.


  9. Berne Miller says:

    Interesting, but……..

    For the past ten years I’ve taught a PMP exam prep course. For the past three years I’ve been deeply immersed in designing, implementing, and rolling out my company’s approach to planning and executing agile software development projects. One thing has become clear……we need to quit thinking PMBOK describes “traditional” project management because doing so allows a lot of folks to get off the good practice hook, saying “Well, that’s my grandfather’s project management and it doesn’t apply to me (or my project/industry)”.

    It does. If you go beyond PMBOK’s mechanistic description of processes, tools, and techniques to think about the concepts on which those processes, tools, and techniques are based, you’ll quickly realize those concepts apply to all projects, its only the mechanics that are different:

    Line Items are sort of like User Stories.
    Schedule Activities are sort of like Iterations.
    Resources are sort of like Team Members.
    Budgets are sort of like Budgets.

    And any project not planned and executed on a sound conceptual foundation is doomed.

  10. Kelly Waters says:

    Hi Berne. The only place I refer to traditional is where I am referencing PRINCE2/Waterfall methods, not PMBOK. I think my point is that PMBOK describes project management generally and therefore it applies equally well to agile projects. Having said that, as we both said, some of the language would be quite different and some of the mechanics or techniques within what is described in PMBOK would also different, especially if you were to drill down a level. I would say that PMBOK and agile methods are largely complimentary, but that the documentation in PMBOK does not do enough to help bridge the gap between ‘traditional’ language and the language used in agile methods. As a result, they tend to seem opposed when really they are not particularly.


  11. Kirk Bryde says:

    Kelly wrote: “For a ground-up build of a back-end system, even every 1-4 months might be challenging in terms of being able to deliver a full working system that has enough value to the users.”

    Kelly, I should have replied to this a couple months ago …

    If the purpose of the release is SOLELY for the customer to use it in a production environment (for real work), then you have a good point.

    However, for “ground-up” projects, the PRIMARY purpose of early releases is for the customer to get a working “prototype” (for lack of a better word) from which they can provide meaningful feedback on whether or not the features delivered thus far are on the right track. If you hold back your releases to your customer until a year or more has gone by, then that’s tantamount to following a waterfall (for lack of a better word) methodology.

    For Agile to work effectively, you need tighter feedback loops. 1-4 months is about the max, IMHO.

    Also, I think the team needs to go thru a few “fire-drill” releases so that when Version 1.0 is ready to be released, it runs smoothly – because you got most of the kinks out in the earlier releases.

    Kirk Bryde, CSM, CSP, PMP

  12. Jeff says:

    Agile is not “project management” the output of agile techniques (not a method either) is a product or an enhancement to a product…it is the “product, service, or result” that is the output of the project. project Management has almost nothing to do with ‘agile”, SDLC, Six Sigma, PDCA etc..project management is the parent of these product management techniques. Part of project processes, upon gathering requirements, the project manager determines what method should be used to complete the product of the project.

    It is this lack of comprehension of what project management truly is that makes people (left brainers mostly) who try agile methods so dangerous to a stable system. Agile techniques are nothing more than an adaptation of RAD and borrowing UML tools, but using “live code” as opposed to prototyping. It was what we used to go after the “dumb money” during the dot bomb…it causes far more harm than good and is full of more holes than swiss cheese.

    When you reward constant change you are guaranteed to get even more of it. Agile is a great technique to rip off customers by meeting “wants” over “needs” and “needs” to have adult supervision if deployed.

  13. Mike Marco says:

    This is a good effort to put some structure in place. Please let me know if you are interested to include your work in “A Guide to Agile Management Body of Knowledge – ABOK”? Since 2008 I have been building this manual. At this point I have 358 pages of tools and
    techniques related to AGILE. Let me know if you would like to join me in
    this effort.


    Mike Marco

Leave a Reply

What is 8 + 7 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)