PMI-ACP Exam Domain: Adaptive Planning Part 1

1. Adaptive Planning Section Overview

Welcome back. A lot of information that we’ve talked about so far and some more information to talk about of course in this section where we’ll look at one of the key exam themes and that is adaptive planning. That adaptive planning builds on those ideas of progressive elaboration or rolling with safe planning. And then how do we do transparent planning. That’s something we’ll talk about in this section. And then managing expectations and planning cadence all important topics that are centered on adaptive planning. I guarantee you you’re going to see these on your exam. So pay close attention to that in this section.

Throughout the course we’ve talked about iterations and having iterative releases and having iterations of work. Well of course then we’re also going to have iterations of planning. So we do iterative planning. That planning is not predictive like we might see in a construction project where planning is more iterative in our life cycle. And Agile, agile projects by nature are risky because risk is an uncertain event or condition. Well in Agile we acknowledge in fact we embrace the idea that there is a lot of uncertainty in our project, that change is going to happen. So we have to plan for risk. We’re constantly on the lookout for the risk that may threaten our objectives.

So we do planning efforts not just for the deliverables, for the value they bring, but we do planning efforts for that ant value for risk. So iterative planning, very important topic on your exam. User stories of course are where we get the value, it’s the functionality and the feature that we work to build in the development team or the deployment team. So we’ll talk about user stories and what are the rules for user stories and how do those get created or written, who’s responsible for those, how do we deliver those and then test all of that’s tied to the user stories.

So these are the items that are in the product backlog that will eventually come into the iteration based on their value. And then those are the things that we deliver for the customer. So a lot of information to learn and to talk about with user stories. Now there are two iteration types I want you to watch out for because I guarantee you’re going to see these on your test. We have iteration zero and iteration h. Not going to tell you now what those mean. Maybe you already know, maybe you don’t, but that’ll be something to look for in this section. So iteration zero and iteration h, two important topics. All right, great job getting ready to complete this section. Let’s hop in and knock it out now. Keep going, keep that momentum. I have confidence in you that you can finish this and I have confidence in you that you can pass the exam. All right, I’ll see you in just a minute.

2. PMI-ACP Domain Overview: Adaptive Planning

Another important topic for your PMI-ACP exam is adaptive planning. So adaptive planning, while it’s not a large exam domain, it is worth 12% of your passing score. So about 14 exam questions. This is all about sizing, estimating and planning. So there are some key tasks for this exam domain. We’ll talk about progressive elaboration and rolling wave planning, transparent planning and key stakeholders managing expectations by refining plans, adjusting our planning cadence based on project factors and results and f course we need to inspect and adapt the plans to changing events. Some more key tasks for you size items first, independently of team velocity so you adjust capacity for maintenance and operations demands to update estimates, start planning with our high level scope, schedule and cost range estimates and then we’ll refine ranges as the project progresses and then use actuals to refine the estimate to complete.

Finally, define adaptive planning. That planning is an ongoing activity, that agile planning is different than predictive planning. We’ll plan for early delivery business value. We want to give value as soon as possible in the project and we want to reduce risk as possible. So just some examples of interactive planning you have your daily stand up, you have backlog prioritization, you have your Sprint Retrospective and iteration planning. These are all interactive and they’re iterations of planning with the goal being to provide value. Okay, a lot of information is a short section but a lot of information for your exam. Let’s hop in and knock it out right now.

3. Defining Adaptive Planning

In this lecture we’re going to discuss Agile planning concepts. How do we go about planning in an Agile project? There are some considerations that we have to take into account for. And so we’ll begin our conversation by talking about adaptive of planning. The Agile projects, we know they’re value driven. So with that thought in mind, with that goal in mind of being value driven, one of the first things that we want to do is minimize non value added work. So anything that doesn’t contribute to value, anything that doesn’t contribute to project requirements and help the project become more efficient, more productive, more valuable, that’s non value add.

So we get rid of it. Now within Agile we know changes are welcome, changes are going to happen. So we plan to replan. And we’ve already talked about this some. We have sprint planning meetings. What are we going to do in this next sprint? We groom the backlog, we reprioritize. So this is part of Agile but it’s also part the same approach happens in XP or Lean or whatever Agile method you want that we plan to replan it’s planning is iterative, it’s never done until the project is done. Now early plans are necessary, we got to start somewhere. But we acknowledge those early plans are probably flawed. They’re probably not accurate because we don’t have enough information. Our competency level is low early in the project. So uncertainty then requires replanting that as more information becomes available then we’re more certain we have a higher level of competency.

We can go back and replan if we consider an Agile project versus a non Agile project like a construction project. So in Agile we have trial and demonstration to uncover true requirements. Remember, we do prototypes and wireframes and different models and then we have that first demonstration to get feedback. Well, we could have that approach in construction. It would be too expensive and it’s more of a predictive nature. We have a very logical approach in construction. We have the blueprints and the architects signs off and we go about building. But in an Agile it’s not a physical thing, it’s more knowledge work. So change is easier when we compare the cost and the time involved to like a physical project, a construction project. So there’s less upfront planning and Agile, it’s more iterative in nature. Also in Agile, mid course adjustments are normal, that the deeper we get into a project we see opportunity and advantages to change direction or to change our requirements with the customer, of course. Also in Agile we have trial and demonstration. As I just mentioned. We do prototypes or wireframes, some type of modeling.

So this helps with that initial planning. It helps us to have that shared vision with the project team and with the customer and the product owner, our key stakeholders. This also helps to avoid the gulf of evaluation. So we communicate Agile planning practices. We say this is our approach. This is how we do it. Here’s what you can expect. This is part of our education as well that we saw in the Agile Manifesto and those principles behind it that we communicate and we educate and we want people to understand the agile approach. Iterative planning of course, is something we’re going to do. That’s the whole theme of adaptive planning. That planning effort is distributed throughout the project lifecycle. When we really step back and look at an agile project, though it’s risky. There’s so many unknowns in an agile project. Well, agile is a way to balance risk because we have iterations of planning planned into our approach.

So we consider our planning efforts over the project life cycle and how do we address risk in each one of those planning iterations? To some extent we address risk every day in the daily stand up. Are there any impediments in your way? Those impediments may already be issues, but they could be risks that are likely or possibly come into fruition. Agile projects. When you think about it, they typically do more planning than a typical predictive project because we have planning at each iteration, it’s planned into the approach. It is agile that we do lots of planning at the end or before each iteration. An exam tip for you changes to plans are normal. Knowledge work, like software development, usually doesn’t follow a predictive plan. So knowledge work and agile, it’s not predictive that we’re responding and reacting and we go through this planning and iterations.

Some principles of agile planning you should be familiar with on your exam. We plan at multiple levels. What that means we plan at a very high level. Where is this project going? What are the requirements? What should we have at the end? But we also plan at a mid level. We think about grooming the backlog and the queue and then we plan at a very tight, close level. What are you going to do the day? What have you done since yesterday? Are there any impediments? And if you want to broaden that a little bit, we also have the sprint backlog where the team does planning.

As to what activities to create the user stories, will they prioritize in the sprint? So we plan at multiple levels. As a project manager, we engage the team and the customer in planning. The product owner is there that’s usually the customer representative and the project team is involved. We also demonstrate our progress and our velocity, what’s our throughput the number of stories that we are accomplishing in each iteration to show where we can likely end up. That shows our capacity for more work priorities will cause the plan to be updated. I skipped over one there tailor processes for the project. Remember that we can tailor and adapt agile processes for what works, but first we need to embrace those before we get too crazy and too bold in our tailoring.

As I mentioned priorities will cause the plan to be updated. Use estimate ranges. So we don’t say that this project will take ten weeks. What we’re going to say is this project we use estimate ranges, we don’t say that this project will take ten weeks instead of what we say is this project will take ten weeks plus or minus two weeks. So we have a sliding window that allows us then to have a range and as we get closer to the end and we’re tracking our velocity we can have a more precise likelihood of when we’re going to finish. So that’s the next point is we base projections on our completion rate so our velocity and will tell us how many points we can accomplish in each iteration and that will allow us to predict where we’re likely to end up in the project. We also factor in diversions and outside work. So we have this idea of ideal time where ideal time is 8 hours of work means 8 hours of work on your project. And so ideal time is this if I say it’s going to take 20 hours to get an activity done, it’s 20 hours of actual working on the project, not 20 hours minus these interruptions and other responsibilities in the organization.

So ideal time is only project work. Agile Discovery is the idea of emergent plans and designs that they emerge as more information becomes available. So predictive plans and designs as we know everything upfront like in construction or manufacturing or even in some It projects that we know exactly what the outcome is going to be like integrating a network topology, but in software it’s more emergent plans. So pre planning activities we do to gather consensus that we bring people together and we want to build consensus and we do this through requirements gathering and scoring those requirements or user stories. As the project moves along, we have that grooming of the backlog, the backlog refinement and prioritization can change based on needs in the organization. We do have to take into account that we’re estimating uncertain workforces, so we take into account that we don’t always know what we don’t know.

So there’s risk if we’ve never done this type of work before, there’s risk if we look at work that we have done over and over and over like a repeatable product or a repeatable project. There’s less risk in our estimating. So with unknowns, which is a risk with work that we’ve never done before, it’s more difficult to accurately predict where we will end up until we get moving in the project, until we move along. So again, we’re planning at multiple levels, we have a high level estimate and then we have a more of a more imminent estimate. It’s like asking someone what are you going to do this weekend?

Probably very likely to tell you what they can do this weekend. What are you going to be doing this weekend? A year from now, that’s so far in the future, who knows? So it’s the same idea on our project. We have a general idea of where the project is going, but the imminent plans are more defined. This leads us into that concept of progressive Elaboration that as more information becomes available, more accurate planning can happen.

So progressive Elaboration recall this is continuing steadily in small increments. So progressive Elaborations, our plans are progressively elaborated. Estimates, risk requirements are progressively elaborated as we begin to ask more questions and find goals and what’s the real purpose behind the project or the desire for the software. We have more accurate requirements and that allows us to better design and then also our test scenarios. So when you think about Agile, you think about progressively elaborated, you get more information, you can more accurately plan. If you can more accurately plan, you can get more information. It’s like a cycle that you are going through.

You’re working from very broad to very specific. Sometimes when we talk about progressive Elaboration, we also hear the idea of rolling wave planning, very similar. Rolling wave planning is planning at multiple points. So you have these waves of planning and then execute and then you plan and you execute. Now progressive Elaboration, the difference though is it’s incorporating new information into the plan. So progressive Elaboration is more of an implementation of rolling wave planning. So rolling wave planning, it’s called that because you have a wave up and down, up and down. The up is the planning, the down is the execution. We’ve talked a lot how Agile projects are value based or value driven projects. Well, let’s talk for a moment about value based analysis. This is where we assess and prioritize the business value of work items. If we look at every user story in the backlog, we could say that each one of those items should have a business value associated to it. So the business value or the business benefit is what the perception of value is, what that thing is worth once it’s implemented, the cost is how much it costs to create it.

So if the business benefit is going to be worth $8,000 and the cost is $5500, then the value is actually $2500. So when we look at these elements in the backlog, we also have to ask some questions. Will the items generate a business value every week or every month? Probably it’s ongoing. Also a high business value item, is it dependent on any lower business value items? Sometimes you can’t get to the high business value item until you have the predecessors completed so that you can get and deliver the high business value. So you have to trace those things back and see what requirements are dependent on other requirements in order to bring them into an actuality in typical project management we do decomposition of the scope. Well, in Agile we can do value based decomposition. So it’s based on a requirement solicitation. And then we create an affinity diagram where we group like features together and then we break down those features and rank them on priority. We could also rank them based on value and that helps us to prioritize. So this is usually done early in the project when we have gathered features or user stories or requirements and then we rank them based on priority.

Well, that point of this is that we want the most valuable items, the highest priority items at the top of that backlog. And this allows us in our execution then to quickly deliver value by quickly creating those high value, high priority items that are in the product backlog. To keep our focused on value, there are a couple of little exercises we can do. One is to create a product box. So imagine a product box or any piece of software and typically it will list about three features. If we look on the back of the Microsoft Word product box here might have some features that tell us about how we can share documents and you can use styles and you can create templates or whatever, but it’s three major features and what are the functional elements? Why do I want this product? So it’s really a visualization exercise to think about what are the valued things that will come about by creating this product or finishing this software development. Another approach is course grained requirements.

So what this does, we don’t get too specific, we don’t get too tight and paint ourselves in a corner that keeps the overall designed balance and then it delays decision on implementation details until the last responsible moment. So by creating a course grained requirement, we don’t up front say exactly what each requirement has to be in very tight language. What I mean by very tight language is that there’s no flexibility, there’s no opportunity for improvement. Instead we keep it at a high level. Then as it’s being implemented, we can get more and more precise. We’ve talked about timeboxing. Timeboxing of course, is a fixed duration period of time. So you define a set of activities and you say, we’re going to do these activities in two weeks or four weeks or one weeks. Whatever your sprint is, of course, the daily scrum of your stand up meeting. That is timeboxed. So here are some timings the know for your exam.

The daily stand up or scrum 15 minutes. A retrospective is about 2 hours. Iterations in sprints, one to four weeks time box sprints. Let’s say we have a sprint that’s going to last four weeks and the team says we can take on these twelve work items over the next four weeks. Well, the team only gets eight done in that four weeks. You take the remaining four items and you return it to the product backlog and then those can be reprioritized. So if you don’t get all twelve done, you only get eight done. You record that because that goes into your velocity planning, but it gives some insight, especially early on. You’re probably going to have some unstable velocity. A term that you should be familiar with as we think about agile planning and especially a sprint planning, is Parkinson’s Law. That work expands to fill the time allotted to it. If you say this task is going to take 40 hours, it will take 40 hours. It’s like the day before you go on vacation, you can get a ton of work done, but the day you come back from vacation takes all day just to do a single email. That’s Parkinson’s law. That’s work expands to fill the time allotted to it. Some of you might know this as the student syndrome, where students wait to the last possible minute to start working. So Parkinson’s Law is something that we want to avoid in our projects.