Ballot Debris

Thoughts on Agile Management, Leadership and Software Engineering

PMBOK, Agile & TOC: Planning the Project - Part 5, Mapping to the PMBOK

clock July 26, 2009 14:52 by author Chad Albrecht

According to the PMBOK the primary output of the Planning Process Group is a Project Management Plan.  However, there are multiple processes that can be used to support the Project Management Plan.  Here they are in order from the 3rd Edition PMBOK:

3.2.2 PMBOK Section Name Relevant Agile practice, process or activity
.1 Develop Project Management Plan Combination of Product Backlog, Release scope, use cases, etc.
.2 Scope Planning We plan scope be defining the features to be included in a release.
.3 Scope Definition Scope is defined as the Product Backlog Items(PBI) that are included in the release.
.4 Create WBS The Work Breakdown is done as part of the PBI to Sprint Backlog Item(SBI) decomposition.  Again, we are aiming for SBIs that are no larger than 16 hours.
.5 Activity Definition Defined in the Product and Sprint Backlogs by User Stories and Use Cases.
.6 Activity Sequencing Activity is sequenced in terms of greatest business value coupled with greatest risk first.  Priority should be set by dollar value as discussed here.
.7 Activity Resource Estimation In Agile we can add or remove resources to increase or decrease velocity.  Depending upon the desired starting velocity (first few release) we can choose the team size based on estimates.
.8 Activity Duration Estimation Discussed in the posts here and here.
.9 Schedule Development Discussed in this post.
.10 Cost Estimation In an Agile environment we plan to deliver continuous value by way of release and iterations. As such, there is typically continuous cost.  Based on the resource estimation we do in .7 and the purchases from .20 we can estimate cost. This has been a sub-topic of a number of my posts.
.11 Cost Budgeting This method not used heavily in Agile.  Rely on Cost Estimation Schedule, CVE and CVP.   While Throughput Accounting is preferred over Cost Accounting PV, EV and AC can be calculated based on current release.  See PMBOK Chapter 7.2 for more information.  More on this in future posts.
.12 Quality Planning Involve QA upfront.  Need functional test for each PBI.  Build release to QA plan.  Quality sign off mechanism.
.13 Human Resource Planning Roles and responsibilities per Agile technique. See PMBOK Chapter 9.1 for more information.
.14 Communications Planning Should include a plan to update stakeholders with burndowns, impediments, roadmaps, etc. See PMBOK Chapter 10.1 for more information.
.15 Risk Management Planning Since risk is reduced in Agile, the planning process is highly simplified.  I will discuss more in future posts.
.16 Risk Identification I will discuss in future posts.
.17 Qualitative Risk Analysis I will discuss in future posts.
.18 Quantitative Risk Analysis I will discuss in future posts.
.19 Risk Response Planning I will discuss in future posts.
.20 Plan Purchases and Acquisitions Plan for hardware, third-party software, tools, etc.
.21 Plan Contracting Obviously required if necessary.

Now we can move on to the project execution part of this series…

PMBOK, Agile & TOC: Planning the Project – Part 2, Estimates

clock June 25, 2009 03:23 by author Chad Albrecht

In my post Planning the Project – Part 1, I talked about the use of financial metrics to determine if we should execute a project or not. In my last post I empirically showed that slight variations in a group of dependent processes can have very dramatic effects on the outcome. So the question is, how do we use these two bits of knowledge to help us estimate? In simplest terms, we want to use some estimation techniques that take statistical variation into account and use NPV and IRR to gauge financial impact. We can use a number of techniques to estimate time and therefore cost. A few of the more popular ones are:

  1. Proxy based estimation. (PROBE)
  2. Parametric estimation.
  3. The Planning Game or Planning Poker.
  4. Putnam model based estimation. (SLIM)
  5. Evidence-based Scheduling. (EBS)
  6. Other various algorithm based models. (COCOMO, SEER-SEM, etc.)

Before we start using any of these techniques, it's good to have a couple of releases under your belt to gauge the velocity of your team. Depending on the Agile methodology, we may want to estimate features, Product Backlog Items, Scenarios, etc. We will want to start by having the teams make a guess at how long it will take to complete these items. I recommend breaking down any item that is estimated for more than 2 days into smaller chunks. Then you will also need to monitor the actual time needed to complete the item. Over a couple releases you should get a better understanding of how good certain individuals are at estimating and how quickly they can actually get things done. Given that information I like to build a "risk factor" or deviation for each developer that is providing estimates. Using this risk factor I can produce min/max estimates more accurately.

Now that you have some data in hand it's time to generate some estimates. I like to use a combination of Evidence-based Scheduling (EBS) and Proxy based estimation. Joel Spolsky has an EBS primer here. Proxy based estimation is simply the act of using similar pieces of completed code as the basis for current estimates, but here again we need data. Let's look at the widget example from Part 1 and look at the specifics. A 6 man-month project is a two month project for a team of three developers. Assuming we use Scrum, we are looking at three development sprints followed by a release sprint. The two week release sprint will be used to stabilize the software by eliminating all the bugs that are deemed unacceptable for release. Each Product Backlog Item (PBI) will be broken into one or more Sprint Backlog Items (SBIs) and used to generate the estimate. I'm just going to use the first PBI which will take the first week of the first Sprint for purposes of discussing estimation. All the other PBIs will be estimated the same way.

Figure 1 - PBI/SBI Estimation Example

Using the historical estimation data you can produce a deviation for each developer that will give you a pretty good range. You can see from the Figure 1 that we have a margin of error of 6.6 days, this is 5.5% of a 120 man-day project. I would be nice if we could reduce this, but let's review what we are trying to do. We are building an ESTIMATE, not an EXACTAMATE! What these numbers really tell you is the confidence you can have in completing the sprints and the release on-time.

I can hear people screaming now, "But Chad! You shouldn't do this in Agile!" Really? I disagree. Agile is not an open checkbook that allows development to just keep working on projects indefinitely, it is a mechanism to Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.1 We still need to create estimates that allow the business to plan on a software release by a certain date. Remember, we can choose to add or remove scope as necessary but we MUST meet our release dates. We estimate to gain a level of confidence that we can, in fact, meet those dates. As we move forward in the release and learn more we will continue to plan and execute as we monitor the project during the execution phase. This is the "Plan-Do-Check-Act" cycle prescribed by the PMBOK.

If you haven't already figured it out, I'm working my way through the Planning Process Group section of the PMBOK. (3.2.2 in the Third Edition) This article covers .3 through .8 and a bit of .9. I'm going to go into a bit more detail on Schedule Development in my next post.


  1. Principles behind the Agile Manifesto -

PMBOK, Agile & TOC: Initiating the Project

clock June 8, 2009 13:06 by author Chad Albrecht

There are many facets to initiating a project according to the PMBOK.  Questions like, “Should we do this project?” and “Will we be able to deliver results?” all need to be answered.  To answer these questions we need to run the core process of this step, Scope Initiation.  The Scope Initiation process has, as do most PMBOK processes, Inputs, Tools and Techniques and Outputs.  Inputs include things like the product or service description, statement of work, strategic plan and historical information.  The Tools and Techniques include things like project selection methods and expert judgment. Finally, the Outputs are the Project Charter and the Preliminary Project Scope Statement.  I will examine the relevance of these documents in Agile Management one at a time.  Additionally, given the fractal nature of Agile development, this step can be used at the release level or at the individual iteration level.

The Project Charter is used to authorize the project and document its business need.  In Agile this step is very important as it helps create a unifying vision for the product or service.  It is easy in an Agile environment to lose track of the original intent, this document can help remind the team of what and why of the project.

The Project Scope Statement defines the deliverable requirements, boundaries of the product or service, methods of acceptance, etc.  This statement is present either implicitly or explicitly in most modern Agile methodologies and is usually represented by one or more artifact.

Agile correlation for these two documents are shown below.





Project Charter

Release and/or Sprint Goal

Vision statement

Informal vision statement as part of overall model

Project Scope Statement

Release and/or Sprint Backlog

Release and Iteration Plan with User Stories

Release and/or Iteration Feature List

PMBOK, Agile & TOC: The Project Lifecycle and Process Groups

clock May 5, 2009 08:36 by author Chad Albrecht

In my last article I established that we have a shot at using PMBOK tools in Agile Management.  Today I want to take a look at how the PMBOK Process Groups map to Agile. As any PMP will tell you the five phases of a project (according to PMI) are:

  1. Initiating
  2. Planning
  3. Executing
  4. Controlling
  5. Closing

While I will examine each in detail, let’s take a high level look at the above and compare it to one of the more prevalent Agile methodologies, Scrum.

Figure 1 - PMBOK Project Management Process Groups

Figure 2 - Simplified Scrum Process

From Figures 1&2 you the correlation between the PMBOK Process Groups and the steps of Scrum should be obvious.  For clarity, I am defining a project in terms of Scrum as a Release.  Some organizations may choose to define the project as the Sprint itself for the purpose of controlling products or services that don’t have the concept of a Release.

Here is the Process Group alignment matrix for some of the Agile Methodologies:




















Release Planning & Product Backlog

Release Planning & User Stories

Develop Overall Model & Build Feature List





Sprint Planning

Iteration Planning

Plan by Feature







Design & Build by Feature





Sprint Backlog & Sprint Burndown

Project Velocity








Release (Build)

So again we see that PMBOK concepts hold up as we examine Agile in more detail.

PMBOK, Agile & TOC: Some Base Concepts

clock May 2, 2009 05:56 by author Chad Albrecht

The first thing I would like to look at is the concept of a "project" and its relationship to Agile. If we are to manage an Agile team using PMBOK base techniques we must first make sure we understand how a project is defined in Agile. The PMBOK defines projects as having the following characteristics:

  1. Temporary
  2. Unique Product, Services or Results
  3. Progressive Elaboration

We can look at how these characteristics line up with Agile one at a time.

We can think of the scope of the Agile release or iteration as the bounds of the temporary work which will be performed. In Scrum this is defined during the Release Planning session, in XP it is defined in the Planning Game and in FDD this is typically done in the Plan By Feature phase.

Unique Product, Services or Results
Of course the work that is being performed by an Agile team will be unique, if it weren't we wouldn't waste the time on it. This characteristic simply reinforces the fact that a project will produce something that the organization does not already have in its possession.

Progressive Elaboration
This characteristic is probably the most interesting and relevant to Agile as it is really what it is all about. The PMBOK says "Progressive elaboration means developing in steps, and continuing by increments." This definition is in direct alignment with the Sprints contained within Scrum, iterations in XP and weekly releases in FDD.

So it appears we may have a chance to align the PMBOK with Agile practices after all.

PMBOK, Agile & TOC

clock May 1, 2009 05:06 by author Chad Albrecht
I've decided to start writing a series of articles on the relationship (and use of) PMBOK based Agile management techniques. These articles will also discuss the use of the Theory of Constraints as it relates to improving efficiency on your Agile teams. Stay tuned...

About me...


I am a leader, entrepreneur, software engineer, husband, father, pilot and athlete. Over the last 17 years of my career I have built numerous successful companies and software development teams. This amazing journey has taken me all over the world and allowed me to work in a number of diverse industries. I have had the privilege to meet and work with thousands of unique and talented people. As you will see from my blog I am a strong believer in Agile techniques and the Kaizen corporate culture. I am always looking to grow myself, my teams and the companies I am partnered with.

Contact me... View Chad Albrecht's profile on LinkedIn Follow Chad Albrecht on Twitter Subscribe to this blog

Professional Scrum Trainer

Professional Scrum Developer Professional Scrum Master I Professional Scrum Master II Professional Product Owner I Professional Product Owner II Certified ScrumMaster



<<  September 2015  >>

View posts in large calendar


Download OPML file OPML

Sign in