If you have customers who are not sure what they want, or you are dealing with unproven technologies, it makes little sense to follow the sort of project planning methodology that is laid down in the Guide to the Project Management Body of Knowledge (PMBOK® Guide). Why go to all the trouble and effort to tie down a set of requirements and to construct a comprehensive Work Breakdown Structure, when your initial thoughts are likely to be taking you in the wrong direction entirely? So what is the alternative to a traditional Project Management approach?

On this page:

• The Agile Approach: Scrum and Rolling Wave Planning
• Scrum and PMBOK Guide Knowledge Areas
• The Visibility and Reassurance of Scrum
• Conclusion

The Agile Approach: Scrum and Rolling Wave Planning

Having sat your PMP® exam, you might be thinking that some form of rolling wave planning (Remember that concept from your Project Management course?!)  is what is needed, which leads us nicely to agile. Agile methods are iterative and incremental. Instead of specifying every step of the way, as you would do in a well-defined project, you do a bit of development and see what the customers think. The feedback then guides what you do in the next piece of development and you build up a mutual understanding with the customers of what the end product should be.

Scrum and PMBOK Guide Knowledge Areas

However, as a good PMP®, you want to make sure you are conforming to the wisdom found in the PMBOK® Guide. You might be comforted by the fact that the Project Management Institute has its own agile accreditation – the Agile Certified Practitioner (PMI-ACP)®. But does this automatically entitle you to use an agile project management technique, such as Scrum? Well the only way to assure yourself is to place Scrum side-by-side with the knowledge areas of the PMBOK® Guide and check if there is a reasonable fit.

Project Integration Management

With Scrum, you are dividing your project up into a series of mini-projects, called sprints. These sprints are two or four weeks in length and include all the process groups familiar to the PMPs® among us. The first part of the sprint planning meeting involves identifying the scope of the sprint, effectively creating the sprint’s charter. The second part of planning takes us into a detailed examination of the features identified for completion in this sprint. Here we estimate durations and create a Work Breakdown Structure for each feature. When the planning is complete, we implement the selected features (execution), all the time monitoring and controlling using Scrum’s task boards and burn-down charts. Finally, the developed functionality is demonstrated to the customer – a form of scope validation (or verification, if you are still working with the 4th edition) – and a Sprint Retrospective is conducted. This retrospective is a project post-mortem and aligns nicely with the closing group in the PMBOK® Guide.

Project Scope Management

Because the requirements list (or product backlog) for a Scrum project is in a constant state of flux, controlling the scope of the venture is very difficult. However, a measure of scope control is possible at the start of each sprint. When a set of features are agreed upon for implementation in a sprint, they are removed from the product backlog and placed on what’s called the sprint backlog. Customers are not allowed to change the contents of the sprint backlog. In this way, Scrum allows flexibility, while retaining scope control.

Project Time Management

Because our project requirements are so volatile, there is little point in building a detailed project schedule for the entire project. However, by ensuring that all sprints are the same duration, the amount of progress tends to average over a series of sprints. Thus we are in a position to estimate how long the current product backlog will take to implement, based on our average rate of progress. However, you might ask: How do we measure the overall size of the backlog, and why bother if it is going to change all the time? An agile practitioner named Mike Cohn has come up with an ingenious solution to this. He created a unit, called the Story Point. He uses these to indicate the relative sizes of features, drawing on the fact that human beings are extremely good at comparative estimating, but we are not so good at absolute estimating. Using story points, a useful size estimate can be made, without going to the expense of PERT analysis for instance.

Project Cost Management

A Scrum team is fixed in size for the duration of the project; the work is divided into fixed-length sprints. So the cost of each portion of the project is readily calculated. Because the rate of progress (or velocity) tends to average over time, the cost of implementing a single story point can be worked out. As the project progresses and uncertainty is reduced – in other words, the requirements become more stable – the overall duration of the project can be estimated with increasing confidence. Thus the overall cost of the project can be estimated more accurately with the passing of each sprint.

Project Quality Management

Before a Scrum project begins, there must be an agreed-upon definition of done. This is the quality benchmark for the project. Whatever quality measures are required by your QA department or your industry can be specified and applied to every single feature that is implemented. The definition of done can be as lenient or as stringent as you specify, but it is consistent across the entire product.

Project HR Management

A Scrum team is a self-managed, multi-disciplinary organization. HR departments are very much in favour of self-managed teams because they tend to drive themselves harder than managed teams do – there is a peer-pressure dynamic at work. Also, the multi-disciplinary nature of the teams removes the silo mentality and encourages the team members to adopt a more holistic outlook.

Project Communications/Stakeholder Management

Scrum is a very visible way of working. During the sprints, progress is openly tracked on a daily basis using large whiteboards, called task boards, and by graphical indications of progress, called burn-down charts. At the end of every sprint, both customers and management alike can see the progress being made by the demonstration. This is an extremely useful two-way street, because, not only do the customers can reassurance that something is being done, the Scrum team gets invaluable feedback and the reassurance that they are going in the right direction.

Project Risk Management

The product backlog is regularly reviewed by the product owner, who seeks to prioritize the features listed in order of value to the customer – the goal being to get the customer up and running with genuinely useful functionality as quickly as possible. However, the rest of the group also has a hand in this process. One of their prioritization criteria is risk. If a feature is very valuable to the customer, but there is a high degree of uncertainty associated with it, then that should go to the top of the list. We want to “fail fast”. If this feature proves to be something that is impossible for the team to achieve, it needs to get that news to the customer as soon as possible.

Project Procurement Management

Customers tend to be wary of time and materials contracts. As you have no doubt learned in your PMP® preparation class, time and materials contracts place the risk firmly on the buyer’s side. However, in agile projects, time and materials can work very much in the client’s favour. There is an interesting statistic in the software world: Over 60% of delivered functionality is rarely if ever used. By prioritizing the product backlog in terms of business value, the customer can receive a perfectly useful product long before the entire product backlog is worked through. If the customer decides that this amount of functionality is perfectly adequate, then it can terminate the project long before the estimated end date.

The Visibility and Reassurance of Scrum

A definite appeal of the Scrum approach is its visibility. The customer can see how the product is evolving sprint by sprint. This is extremely reassuring, as it can be nerve-wracking waiting for a project to finish when you are not sure what the end result will be.

Conclusion

So, on balance, the Scrum methodology can hold its head high in the context of the PMBOK® Guide. It is effectively a form of rolling-wave planning with a strong tendency to avoid gold-plating, as worthless features tend to be pushed toward the bottom of the backlog. So if your project lends itself to the Scrum approach, the PMI at least will not oppose you. Good luck!