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 4 + 3 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”