Passing the PMI-ACP (Agile Certified Practitioner)

Why I Took It

I've been using Agile approaches for the past couple of years and knew that there was much I hadn't learned yet.  I wanted to broaden my understanding and have a way of easily communicating to folks that I have this skill.  I saw 3 options:

Compensated
Affiliate

1. CSM (Certified Scrum Master).  This is the most popular industry-recognized credential.  It is also the easiest to obtain.  Unfortunately, that's also it's downside: if you have 21 PDUs and can pass the exam, you're a CSM.  Even Agile Purists don't like the fact that folks with no required experience can call themselves "Master".
2. CSP (Certified Scrum Professional).  The creators of CSM - Scrum Alliance - more recently came out with the CSP.  (CSM is a prerequisite for CSP.)  It addresses the shortfall of CSM by requiring prior experience - at least 2000 hours over the past 2 years. 
3. ACP (Agile Certified Practitioner).  This is PMI's Agile offering, which is interesting as they have long held that the PMBoK/PMP covered everything including Agile.  The recommnded reading list doesn't even include PMBoK (although it's assumed you already know it well.)  I'm glad they have something specifically for Agile, because it IS different.  There, I said it.  It one-ups CSP in that you have to maintain your certification with ongoing PDU's.

I went the ACP route for the following reasons:

1. The ACP exam - and therefore preparation materials - cover more than just Scrum. I like Scrum - it's the only framework I've used, but it's not the only one out there.  I wanted to better understand XP, DSDM, Kanban, Crystal, Lean etc.  The ongoing PDU requirement gives it more credibility than CSP.  You simply can't sit on your laurels in this business.
2. PMI is the most widely recognized authority for Project Management.  I'm a consultant and the credentials matter.  (If you're not a PM, CSP may be a stronger option.)
3. I already have my PMP which takes care of some of the prerequisites.  I would have had to get the CSM before I could start towards the CSP.

How I Passed It

I scored the highest rating in each knowledge area.  (Better than I did on the PMP!)

PMI recommends 12 books on a variety of Agile topics - some of which I have previously read.  However, I didn't want to purchase and read all of these books right now, so I kept looking for help.  Here's what I went with...

Agile PrepCast - more information (compensated affiliate)

I listened to an episode of Andy Kaufman's terrific "People and Projects Podcast" in which he interviewed Cornelius Fichtner of "PM Podcast" fame.  The subject was the PMI-ACP and Cornelius was promoting his Agile PrepCast.  I followed up and learned that I could get all the required PDU's via podcasts on my iPhone.  I had already calculated the cost of out-of-town Scrum learning and this came in at 5% of that.  I also much prefer learning at my own pace. I was sold!! 

Exam Prep Book by Andy Crowe

Andy's PMP exam prep book was excellent and so this was a no-brainer for me when it came out.  It is brief and covers only the essentials.  It will help you pass the exam, but it is too shallow to be a real Agile learning tool.  That's a perfect compliment to the PrepCast which went into much more detail.  It comes with 2 practice exams, which I thought lined up well with the actual exam.

Agile Books and Practice

I have read a few good books on Agile over the past couple of years, most importantly Mike Cohn's Agile Estimating and Planning.  This is focused on Scrum methods, but it's a great place to start for Agile newbies - and a solid reference for more experienced folks.  Other good books: User Stories Applied (Cohn), Project Management the Agile Way (Goodpasture), Crystal Clear (Cockburn), and Lean Software Development (Poppendieck.)
It certainly didn't hurt that I had run several significant Agile projects over the last couple of years.  Much of the learning served to formalize and crystalize the knowledge already in my head.


Let me know if this information has been helpful to you - and I wish any of you seeking certification the greatest success!

When Is A Requirement Not A Requirement?

 



Agile is supposed to provide a certain amount of elasticity in a project.  Scope isn't a prison cell, but an uncharted country to be explored and defined as opportunities and obstacles present themselves.  Okay, perhaps that's a little romantic, but the idea is that scope can morph as things progress.  Change is good, not bad.

Some Agile projects nevertheless end up with heavy scope-related tension.  Agile promised the business that they could have whatever they wanted within the given time and budget, as long as they engaged in continuous value-based prioritization.  "If you want to put more water in the bucket, you have to empty some out first."  This quickly becomes a problem, however, when nothing in the bucket is expendable.  "We've had a great idea, but can't afford to take anything out to make room for it."

Hello tension.

The project manager has three bad answers to choose from:

1. "That's phase 2!"
2. "That's a change request!"
3. "We'll squeeze it in somehow!"

What went wrong?  Agile was supposed to allow for flexibility in scope - it's the one point on the iron triangle (budget-schedule-scope) that was not fixed.

The problem may well be with the water in the bucket.  If all the water is needed - if all scope is considered  necessary - then you really have no room for flexibility.  The budget and schedule may have been carefully and accurately planned to account for the amount of scope in play, but all of the requirements are required.

Enter MoSCoW analysis.  It stands for:

• Must have
• Should have
• Could have
• Won't have

This is an old method for categorizing requirements.  We all typically do this at some point - evaluating what simply has to be done, then focusing our attention on those things.  Often, everything else is deferred, having been deemed unimportant.

Agile can make excellent use of MoSCoW, although in a different way.

In the planning phase of your Agile project, help the business see the requirements through the MoSCoW filter.  If everything looks like a Must Have you have a problem: these requirements are required... they aren't negotiable, and when you need scope flexibility later on, it won't be there.

If everything is falling into the "Must Have" bucket, the business folks probably aren't thinking hard enough.  Even if all of those requirements are critical, there are always other requirements that are less so - dig a little deeper.  In the rare case where this isn't so, scope is fixed and Agile is probably not the right answer.

So how many requirements can be required?  A rule of thumb is 60%.  The business expects to get 60% of the project scope delivered - anything less is failure.  They've made commitments and they expect you to do the same with these requirements.  The other 40% is malleable.  That's your scope flexibility.  When something new comes up midstream, one of these Should Have or Could Have requirements can be taken out to make room for it.  Or, perhaps de-prioritized... moved below the line.  (The line may move as things take more or less time than expected to complete, perhaps bringing that requirement back into the project.)

Remember that not all requirements are created equal.  Some are not required.  Be clear up front with the business about this, and work with them to find what aren't Must Haves.  This is essential to maintaining scope flexibility, which is essential to Agile.

Burndown Charts 2: "Detailed Burndown"

So we've looked at a Simple Burndown Chart as a way of representing progress on an Agile project, now we'll look at one that presents a little more detail.  As a reminder, there is no one-size-fits all approach to release burndowns: you have to tinker with it to suit your audience and the type of work. 

I am leading development teams for Covenant Technology Partners, a consulting firm that heavily leverages Microsoft technologies.  My clients are typically new to Agile, and most have never seen a burndown chart before.  So I want to keep it simple, showing schedule, scope, and budget in a way that flows with our 2 week sprints.  I report on other things, such as progress against themes, and issues/risks, but I'll discuss those another day.

The key difference between the charts below and the simple charts in the first post is that these separate the impact of velocity from scope changes.  I can now see how many points the team is burning in each sprint, unclouded by variability in scope.

Burndown Showing Scope As Negative

The blue bars represent the amount of work remaining on the project.  Everything above the zero point line is what remains of work added at the start of the project.  Everything below the line represents what remains of work added after the start. 

The advantage of this over the simple charts is that I can see how the team is performing - every point delivered comes off the top of the chart.  Now I can draw a straight (blue) line and get a better idea of velocity.

As stories are added to the project, the bars extended beneath zero.  Of course, they can also shrink as stories are removed from scope.  I've added a green trend line for scope growth - I'm using a log (curve) not linear (straight) line because I anticipate that most new scope will get added earlier in the project. 

What matters most now is not when the blue line crosses zero, but when it intersects with the red dotted line - that is when all stories will be complete.

The drawback of this chart is that the negative growth is unintuitive for many, requiring additional explanation.  Also, it seems that I need to add extra sprints in order to show the intersection line (assuming more scope is being added than will fit, which is typical).  The problem is that my budget only covers 7 Sprints, but the chart now implies 8.

Here's the data behind the chart.

Burndown Showing Scope as Positive

This chart seems to work best for me.  Again, velocity is clear and so is the total scope.  In this scenario, the project has 7 sprints and there will be about 30 points left in the backlog at the end of Sprint 7.  Here is the source data.

Scope Creep?

Unlike waterfall projects, scope on an Agile project is intentionally fluid.  We don't lock the business into a predefined list of deliverables, but instead allow - even encourage - them to modify scope along the way.  That means that original vs. new scope is largely irrelevant.  (Shocking, I know.) 

The problem with burndown charts that show scope growth is that they tend to imply that new scope is "extra" - and therefore, bad.  Scope creep.  When presenting this chart to the business, we have to take care to avoid communicating this.  Instead we should state clearly that the only reason for separating out original vs. new scope is that it allows us to track team performance. 

What the business wants in the backlog is entirely up to them.  They just have to square it with their budget - which in an Agile project equals schedule.  In the above example, 30 points will not make it into the project.  This is not a bad or unusual thing: as a project moves along new value is envisioned and added in.  The key is for the business to prioritize the backlog (in collaboration with the project team), so that the 30 points represent the least important user stories.

Beware Certainty

Don't read too much into the lines.  This is Agile, and averages can be misleading.  If a team completes 20 points in Sprint 1 and 40 points in Sprint 2, the velocity is not necessary 30 points.  It is likely between 20 and 40, and that means the "line" could cross the zero axis in a couple of different places.  I.e. It might take 5 sprints, or it might take 7 sprints.  Save yourself some headaches and be sure to communicate this to your client.  Velocity will become clearer and the ranges more narrow as the project progresses, but it will never be fully understood until the project is complete!

Burndown Charts 1: "Simple Burndown"

Burndown charts are used to communicate the progress of an Agile project clearly and quickly. They speak to scope, schedule and even budget (assuming the budget is enough to get you through the number of sprints included in the chart.) The chart isn't a status report, but is a key part of one.

With burndown charts, however, there is no one-size-fits-all. Simple charts communicate information quickly, but at the expense of important information. Complex charts provide more insights, but can be difficult to digest. This latter point is especially important if your audience is new to Agile approaches.

This means that you will have to figure out what works best for you and your stakeholders, and make it work.

That is the process I am going through right now, and I will post what I've developed along the way. The first post will look at...

Simple Burndown

The simple burndown chart shows how much work will get done before time (and money) run out.

Ideal Progress

The green dotted line is a straight line from the beginning of scope and time to the end of the project. This chart shows an 8 sprint project. The idea is that the blue "actual" line remains close to the ideal line. If reality isn't close to forecast, you have a problem. This will happen. That's why you're a Project Manager. Here is the small table the above chart is based on:

Work Remaining

The backlog started with about 170 user story points, and the team has completed all but about 60 of those. The marker points show how many points remain at the end of each sprint. I found this a little counter-intuitive at first: the line is only extended after the sprint is completed. This means that the number shown in Sprint 5 (~60) is actually reflects the work still in play for Sprint 6.

New Work

Unlike waterfall methods, the Agile approach allows - even encourages - change. This means that scope will be fluid throughout the project, with user stories being added and removed along the way. In the simple chart it is not possible to discern between the effect of completed stories and the adding/removing of stories. How much progress did the team make in Sprint 5? The chart shows a reduction of about 20 points, but if 10 points of new scope were added, then the team really completed 30 points. Simplicity comes at the expense of understanding team performance (velocity.) This chart shows the progress of the overall project more than that of the development team. Here is an example of a chart and its source table that includes new work:

Bugs

Bugs happen. Plan on it. So, do you include bug stories as added scope, or does the team velocity just take a hit? I'll write more on this later, but for now I'll just state that I do the latter. Bugs are recorded as stories, but I don't ever count their points. This means the burndown doesn't reflect all of the work the team is doing, but this shouldn't be a problem as long as the bug-related points are nominal and fairly consistent across the sprints.  Bottom line is that bugs are a drag on velocity - and that's probably the right way to think about them.

Budget

Budget is implied in the schedule. Typically, the budget is set at the outset of the project (another post, another day), and combined with the cost of the team over time, this determines the number of sprints. Don't forget that there may be other costs in the project than just user story development...

What's Not in the Chart

I only use the burndown chart for the "build" portion of the project. Planning work that precedes it may not involve the whole team, and will likely not consist of delivering user stories. Work following may involve user acceptance testing and other tasks, again not relating primarily to user stories. Velocity doesn't seem to have much bearing outside of the build phase, which is why I have only (so far) used the burndown for that portion of the project. I'd be interested in other thoughts on this.

Summary

The Simple Chart shows the least amount of necessary information and is easy to understand. This might work particularly well with stakeholders that assume a burndown chart is a song by Talking Heads. For more informative charts, you'll have to wait for the next post...