PMI-ACP Exam Domain: Adaptive Planning Part 2

4. Exploring the Agile Planning Concepts

Once we’ve created the user stories, the project team and the product customer, the customer representatives, they’ll work together to begin scoring. How large or how much effort will it take to create eight these user stories. So that’s what this next couple of lectures are about, about project sizing and estimating. One of the first things we’ll do when it comes to estimating a project is to give an estimate range. We talked a little bit about this in the last lecture where we don’t give an exact amount, we give a range of variance. So for example, this project will take 26 weeks plus or -10% or this project will cost between 500 and 550,000. So it’s a range of variance and that’s because there’s more uncertainty with an agile project. Of course, agile projects or knowledge work projects, they just can’t be as precise as predictive planning.

Now, a convergence graph is a way of showing that early in the product where we have a low competency level about the details of the project. In other words, there’s a lot of unknown details. The range of variance is really broad because there’s so much that we don’t know yet. But as we move deeper and deeper into the project, the range of variance begins to diminish. You can see those two lines coming together where that’s the spectrum of possible cost as far as effort and size. So this makes sense, right, that as more information becomes available and you get closer and closer to the end of the project, you’re more likely to be able to accurately estimate the cost and the size of the project.

We do need to create some agile estimates. So why do we have to create an estimate though, if agile is so unknown and it’s so forgiving and it’s so easy to work with and change is going to happen? Well, we have to start somewhere and I need an agile estimate to create a schedule and a budget. So when does estimating happen? Estimating will happen at the last responsible moment and throughout the project. So it’s different than a predictive project where we have lots of information up front and we can plan up front. And be very maybe not very precise, but more precise than what we have here. Team members estimate their own work. Team members are closest to the activities, to doing the development and the testing. So they will predict how long it takes to complete a user story or to create a feature.

Now, estimates are created based on stages of sizing and planning. Basically a way of saying early on, estimates are very unreliable. As we move deeper and deeper into deeper stages of the project, our sizing and planning can become more accurate. Now, estimates are always stated with a degree of uncertainty. That’s a really important point, both for the exam, but also for your role as an Agile. PM I talked about ideal time in the last lecture. Let’s just be real clear about this factoring. Ideal time means that when we estimate, we estimate as if there would be no interruptions. So ideal time assumes and the estimate is all for the project work. So if we say this activity is going to take 8 hours, we don’t say it’s going to take 8 hours of labor, but I’m going to have two or 3 hours away so I’m going to say it takes 11 hours.

No, we only factor in ideal time only the labor for the project is what’s estimated. Continuing our conversation about assumptions for sizing and estimating. As the project moves forward, more details are going to emerge. As we do demonstrations in our Sprint review and as we work with the product owner to prioritize resources, plans are going to be adjusted based on that feedback that we received. So prioritization, not privatization. Prioritization happens throughout the project that priorities shift and change. Decomposing project requirements. It’s a breakdown of the project work. So there’s a couple of different categories. There are actually four different categories of things that can be in the product backlog that we need to address. The first one is what’s called an epic. An epic is a large user story that can span one or more iterations. It’s a really big user story. Usually it’s probably too big, it needs to be broken down. But there are instances where an epic could span more than one iteration and that’s just the way it is. A feature is an attribute of the product, the user story. The most common is the decomposition of a feature.

If we break features down again we have the task and that’s what we get in a Sprint backlog. So this is the product backlog and then task we get in the Sprint backlog. I’ve mentioned user story several times and I don’t think I’ve accurately defined it. I’ve kind of made an assumption here that everybody knew what a user story is. Let’s just be real clear that a user story, it’s like a small chunk of business functionality. So this small chunk of business functionality, it’s tied to a feature. It involves roughly one to three days of work to create that’s a user story. It could also be defined as just 40 hours of work. So it’s another way to look at it. User stories are written on index cards or sticky notes and then they go into the product backlog and they’re prioritized. So a user story is just a chunk of work that is tied to a feature of the thing you’re developing. In order to create a user story you first begin with potential stories and these are called candidate stories and all of these are from the perspective of the user or the customer.

So they’re written in this little formula where you say as a role I want to do what functionality so that I obtain this business benefit. So as a role I want functionality so that I obtain this business benefit and you can see the role there. It’s not a role like a biscuit, it’s role being like a role in responsibility. All right, let’s not let that distract us. It’s already bothered me anyway. User stories so as an end user I want to be able to print so that I can mail out my marketing material or whatever. So it’s a role, functionality, business benefit. Know that sequence role functionality, business benefit. It answers two questions who was asking for this and why are we doing this? So who is the role? Why are we doing it? Functionality business benefit. So some user story formats another way you could say given when then given the scenario for the story when the action takes place. This is the result of the action. As an end user I print so I have the document and I can mail it out. All right, so that’s given when then there are three C’s of user stories.

We have the card, just enough text to identify the story. The conversation, the details are communicated via conversation between the customer and the development team. And then we have a confirmation where the customer confirms that the story has actually been implemented in the product correctly. Effective user Stories follow this invest approach. Know this invest approach for your exam. It’s independent. The stories can be prioritized by any order. It’s negotiable. The team can discuss the user story with a product owner and they can make tradeoffs based on cost and function. It’s valuable. The user story will have obvious value. If it doesn’t have obvious value, it doesn’t need to be a requirement. So it needs obvious value estimate or estimatable estimate. The user story can be estimated for effort. It’s small. User stories are easy to create and we don’t want to have larger stories. They’re easier to create, easier to test.

Those larger user stories can be more complex. So we want to keep it between four and 40 hours of work. And then finally you can create a test on its testable that the story results must be testable to confirm that you have achieved the definition of done. Now defining the user story backlog it’s also known as the product backlog. We’ve talked about this. The stories are listed and sorted and then prioritized. There is only one backlog for the project. So one backlog, all requirements, all user stories, all features, all for one project. One backlog. The product owner grooms the backlog so it’s continuously updated. Just a way of going in and prioritizing and refining the backlog. There will be times where there’ll be changes to the backlog where new stories can be added or existing stories might be reprioritized or removed. Stories can be decomposed into smaller chunks. Customer or the value management team can add new stories or reprioritize existing stories. There will be times where a story is really just too large. It needs to be decomposed again. And so it’s called slicing and slicing down. The story is typically done by the development team in the task.

5. Reviewing the Tools for Project Sizing and Estimating

In the last lecture we talked about user stories and the product backlog and all the characteristics of user stories. Well, in this lecture we need to talk about estimating stories. How do we score the value of stories? And by that value, I don’t mean a financial value. I mean how much time and effort will it take in order to complete the story, to create it during an iteration? Well, what we use is an approach called relative sizing. It’s difficult to make an absolute estimate for each one of our stories. You might look at one story and say, well, it’s going to take 36 hours. And you look at another one and you say, well, this one will take 25 hours.

Well, how do you really know one’s going to take 36 or 25? How do you say one’s? 36 and this one’s 37? Well, relative sizing uses the concept of story points. So they’re assigned to story size, so it keeps them in this kind of a sliding window of sizing. So relative sizing assigns points based on this relative scale, and then the team decides how many points can be done. In our iteration, the Fibonacci sequence is kind of a little mathematical riddle or puzzle that goes back to Leonardo DA Vinci. So what the Fibonacci sequence is, is that you start with zero, and then two numbers in the sequence are added together to get the next number in the sequence. So for example, zero plus one is one. One plus one is two, two plus one is three.

And then you go on from there where you would have two plus three is five. Five plus three is eight. Eight plus five is 1313, plus eight is 21 and so on. And it kind of makes this little seashell of this pattern. So it’s just a very unusual mathematical complexity. How most designed, especially in nature, like a starfish or a shell, even in a tree, the number of rings in a tree, they all kind of follow this Fibonacci sequence starting from the center outward. It’s like a big seashell. So we only use though, the numbers 1235, 813 and 21 to assign points to scoreys. So if you think about it, it makes sense. Like you’ve got a little tiny story. You might say, okay, it’s one, two or three. Those are all tiny. One, two and three. Really tiny. All right, five is definitely bigger than one, but five is definitely considerably less than eight.

So you look at your list of stories, you say, well, this is a medium size story. I think it should be an eight. And then someone else says, well, I think it’s a little bigger than medium. Let’s make it a 13. And then you still look at another one, you say, whoa, this is a really big story. It’s going to be 21 points, or not quite 21, so it’s going to be 18. So you see, as you get bigger and bigger, there’s more uncertainty. So there’s a bigger range of variance between 13 and 21 than there is between three and five, or one and five for that matter. So it’s just a way of using relative sizing. And that’s called the Fibonacci Sequence. Know that for your exam. And there’s our seashell again. I know you like that. Some other guidelines for story points. The team owns the definition of their story points. They don’t have to use the Fibonacci Sequence, but most agile teams do. Story point estimates should be all inclusive, meaning we’re not factoring in breaks or interruptions or other work. It’s just how much actual ideal time is needed.

And the point sizes should be relative, like we just looked at. And then when you do some disaggregating estimates, the totals don’t need to match up. So if you were to sum all of these up, it doesn’t have to equal a magic number. It doesn’t have to be 100. Complexity, work, effort, and risk are all included in the estimate. So you take into consideration how complex it is, how much labor or time, or the amount of how tedious it may be, and then also the risk. And that all contributes to how you score that story. Affinity estimating is another approach of grouping items into similar categories or collections. So you can group items based on story points, just like what we did earlier.

Affinity estimating is also like triangulation. So you could say that if this one story here represents five and this is a really big one and it represents 21, then you can say, well, it’s somewhere between the two. So you make kind of a triangle. You say, okay, it’s got to be an eight or a 13. Or if you say this is large, this is extra large, then this guy here, I’m going to say it’s relatively closer to extra large, so I’m going to make it a large. So triangulation, it allows to see the team to look at the collection of user stories by points assigned. And so you want to be able to just step back and say, okay, this isn’t large or small. These have actual points assigned that represent the difficulty level to create these and make these things a reality. A good example of triangulation is T shirt sizing. So I kind of got ahead of myself there. I said extra large to small, that’s triangulation.

So user stories can also be assigned to T shirt sizes, from extra large to extra small. Now, Story maps, it’s a high level planning tool to help you map out your project priorities. So you have this matrix of features and user stories, and then you put those based on priority from the musthave to the least important. So what we get by this is a backbone. That’s the top level of the story map. And then we get this walking skeleton. It’s the second row of the story map. It’s the smallest version of the system that will beat the customer’s most basic needs. Let’s look at this. So here’s the story map. So you can see the user activities. That’s the backbone, if you recall, these are the top level, the essential functions, the things that have to be in the software. And then we get this walking skeleton. This represents the minimum software requirements. Then we have priorities, user stories prioritize for each release of the software. So here’s our time going left to right and then we have priorities from the top down.

And so this is a way, this is just a story map. You’re mapping out requirements and then the prioritization of those requirements, you’re mapping out the user stories all the way down from most important to least important. Another approach we can take is to create a product roadmap. It’s a visual depiction of product releases. So this has the primary items that are going to be included in each release and it helps to check us for risk and the viability. Is this really viable to do this amount of stories in this release?

The delphi technique, sometimes called the wide band delphi, uses rounds of anonymous surveys to build consensus. So what we do with the wide band delphi is we all meet in a room and we anonymously vote on the value of stories. And so then those story points are voted anonymously and then we gather those up and we look at those and sort those and share that with everyone else in the room. So it’s all anonymous though, so it keeps everyone from drifting to one answer, one solution. It also gets rid of the bandwagon effect or what’s called the hippo, the highest paid person’s opinion. And it gets rid of group thing where we just all whatever, whoever says the answer first is what we all agree to. So wideband delphi is rounds of anonymous surveys to build consensus. Now probably the most common game when it comes to agile is planning poker. So Planning poker, really simple concept. Let’s say there’s seven or eight of us in the room, or even a dozen of us in the room and we are going to estimate stories.

We all get some index cards that have the Fibonacci sequence printed on the index cards and we look at a user story, we all agree, okay, we’re looking at user story A or B or what have you and then we decide how many points we’re going to give to that story. And so we put that card face down on the table and everybody does this. And then all at once we turn it over and then we can see around the room. I’ve got a three and you have an eight and Jim over there has a 21 and Nancy has a 13 and what have you. So it’s a way of scoring it anonymously but it’s called planning poker because it looks like you’re holding a deck of poker cards. Not nearly as much fun. All right, that brings us to the end of this lecture on estimating and planning and Sizing projects. User stories and an Agile project. Great work.

6. Planning for Releases and Iterations

A theme that we’ve seen throughout this course is that Agile projects will have releases and iterations. Iterations are Sprint and of course we have multiple releases where we have some type of a product to demo at the Sprint review meeting and then ultimately it’s released. Well, that’s what we’re going to talk about in this lecture. It’s all about planning for these releases and iterations. What are some things that we have to do in order to be successful with releases and iterations? Well, let’s begin by defining releases and iterations. I think you know this releases are the publishing of the software, happens at the very end. Now iterations though are short timeboxed periods of development like a sprint, they could last from one to four weeks, typically two to four weeks, but Sprint or iterations now one iteration is called iteration zero.

Iteration zero is setting the stage for developments, getting everything ready. So there’s typically no real deliverable for the customer in iteration zero. But it sets the stage and it prepares the environment to allow us to do the work. Then we have iteration H. This is also known as a hardening sprint or a wrap up sprint. It’s a special time at the end of the project that we use this time to stabilize the code, do any documentation for the product, the final compiling of the software, and then any final testing. So it’s kind of hardening. That’s why it’s iteration H. Now throughout our iterations we might have some spikes, architectural spikes and a risk spike.

And I mentioned these a long time ago in the course. Let’s just touch on these again. An architectural spike is a short amount of time to go and to test or do a proof of concept about the approach that you’re going to do. Is it even viable? Can we support it? Do we have the architecture to support it? So it’s kind of a research assignment but it’s really small. It’s like a special time just to research the architecture of the software or platform or system. Now a risk based spike, very similar, but we’re investigating risk. It’s a short effort, small amount of time, but I’m looking to reduce or eliminate the risk event through mitigation. Now mitigation what it does, it reduces, it lowers the probability and or impact of a risk event and recall.

In Agile the risk is always negative. It’s good for new technology. Typically you do this early in the project. So a risk based spike and architectural spikes, know those two terms for your exam. I know you already know them, but make sure you know them. Then we have high level planning and we’ve talked about visioning and the shared visioning. Well, this is part of our iteration planning and release planning. So it’s prior to planning the first release, bapt out the overall effort of the project. It’s done with the product owner and the sponsor, your key team members and any other major stakeholders that have a lot invested in this software project you’re doing. But this is how we get the shared visioning outputs of high level planning. You have an updated prioritized backlog. You have course grained relative estimates for each user story. You’ve defined the goals of the release and you have a target release date.

As the project manager, you’ll need to periodically host a release planning meeting. This is before every release that you do. So all stakeholders are representative. Doesn’t mean you have to have every end user there. Usually you have a representative from the end users. And then in this meeting, the goal is to find out which stories will be done in which iterations for the release. So it defines your upcoming release and then also defines future iterations for future releases. In this meeting, your goal is to assess the prioritized backlog.

You’ll review story sizing. You’re going to sort the stories by release and then define the initial outline or that product roadmap for the release. You may need to slice the stories as needed for the planned release. Recall that slicing the stories is just a way of breaking them down even more in the task. Usually the development team does the slicing. So we have two types of stories that need slicing. You have these compound stories. These compound stories include other independent stories within the project so they’re kind of related or mushed together if you will. And then you have Epics where it’s just one large complicated story and it usually can’t fit within one iteration. Those both need to be sliced down. Iteration planning is where we have a meeting for and facilitated by the delivery team. It’s what are we going to do in this current iteration.

So you’ll talk about the user stories that have been prioritized that will go into the sprint backlog and then that’s how you select the user stories for the iteration. It’s based on priority and it’s also based on that relative sizing where you’ve estimated the duration or the size of the user stories. And I want to be clear that you don’t estimate the duration, you’re estimating the size. It’s the number of user stories that your team believes they can accomplish in one iteration determines how many stories will they take on.

Also in iteration planning, you look at the acceptance criteria. This is where that acceptance test is written. You’ll break down the use for stories and tasks. You’re going to take those user stories and break them down again into the individual tasks that you need to accomplish in the iteration and then you’ll estimate the task as well. Recall that velocity shows our throughput, shows our capacity as a team. We have those burn up charts and the burn down charts and then we track our velocity because that allows us to predict how long will it take to finish an iteration.

Throughout the iteration we have the daily stand up. Now this is a really important thing you want to know for your exam. These are the rules for the daily stand up. So I encourage you to pay attention to these. Write these down. You definitely need to know this for your exam. People with a task, any task, they must attend. Only people who have tasks can speak at this meeting. Address the entire team, not just the scrum master. No side conversations. Any new task that’s identified, you, put those in the sticky note if they are started, any issues that come up, you discuss those issues after the stand up, and then you solve problems offline. So those are the rules. You need to know those for your exam and to be a good, agile project manager. All right, great job finishing this little section. Let’s keep going.