Adaptive Planning - Agile Planning and Time boxing: PMI ACP

This is ‘Adaptive Planning - Agile Planning and Time Boxing: PMI ACP’ tutorial of the PMI-ACP Certification course offered by Simplilearn. In this part, we will learn about Agile Planning, Levels of planning, Timeboxing and Story Point Estimation.

Objectives

After completing this lesson, you will be able to:

Identify the multiple levels of planning in Agile projects

Explain how Rolling wave planning is applied in Agile projects

Explain the principle of timeboxing

Explain relative sizing and story points

Describe the concept of Ideal days

Explain Wideband Delphi and Planning Poker Estimation Technique

Describe the Affinity Estimation technique in Agile

Multiple Levels of Planning

Agile projects planning at multiple levels often represented through the “planning onion.”

Long-term planning begins at the strategy layer, which includes business goals and roadmaps agreed to by the executive leadership.

At the next level of planning, the organization’s management finalizes the product portfolio. Portfolio planning involves selecting products that will best implement the vision established during strategic planning.

At the product (emphasize) level, the product owner plans the product release roadmap, usually for a 1–2 year period to support the portfolio and strategic vision. Product planning also involves looking beyond the immediate release and planning for the evolution of the released system. To develop high-level product features, it is important to consider market and competitive pressures, customer feedback, and technological advances.

The next level of planning, release planning, considers the deliverables and features of each release that support the product plan. Releases are typically more detailed than a product plan, but still quite coarse-grained, focusing on deliverables for the next 3–12 months.

Iteration planning considers the tasks needed to transform a feature request into a working, tested software, and occurs at the start of each iteration.

It details the user stories to be completed and made ready for release in one iteration, which often ranges from 1–4 weeks in duration. Planning also occurs daily in Agile projects through the Daily Scrum or Stand-Up meetings, which drive the day-to-day activities of the team.

Aligning Agile Projects to Programs and Portfolios

As discussed, Agile projects support the vision and goals of Programs and Portfolios that can extend for years. This is enabled through:

Themes and epics, releases, iterations, and user stories. Themes and epics are used to support the long-term vision of Portfolio or Product Roadmaps. These are high-level, coarse-grained features or requirements that will be refined later when releases and iterations are developed. The product backlog contains all the features identified by the Product Owner from a variety of sources such as customers, focus groups, users, and even competitors.

Releases support the Product Roadmaps. The release plan specifies how to realize the Product Roadmap or Product Portfolio over time. Within each release, which usually lasts between 3-12 months, there are a series of iterations or sprints. The release backlog is a subset of the product backlog and is supported by an iteration or sprint.

These timeboxed activities break down a release further into smaller, more manageable parts. Only upcoming iterations are planned in significant detail so that as business requirements change, the project team can adapt and adjust its plans. Each iteration or sprint contains user stories, which are details of the project requirements the project team commits to deliver at the end of the iteration.

Rolling Wave Planning or Progressive Elaboration

Let us understand Rolling Wave Planning in detail here.

In rolling wave planning or the progressive elaboration method, the plan evolves as the project progresses. In this method, projects are kicked off with limited available information, which is used to create a high-level plan and estimates. As details emerge later in the project, plans and estimates are constantly revised to ensure they remain valid and current.

Project details for an immediate couple of months are fine-grained and detailed. But further down the project timeline, only Rough Order of Magnitude or ROM details are available, which must be continuously refined and elaborated as more information becomes available. It is rare to encounter projects with all the details available upfront; rolling wave planning is useful where project information is limited.

Details that would evolve through progressive elaboration are:

Project Plans

Estimates

Requirements

Risk

Acceptance criteria

Definition of ‘Done’

Testing

Architecture and design

The purpose of progressive elaboration is to improve the predictability of outcomes through constant planning and deliver high-value features by exploiting opportunities.

Rolling Wave Planning or Progressive Elaboration (contd.)

In the image illustrating rolling wave planning, the blue circles represent the planning activity that happens at the start of every iteration. Orange circles represent the sprints where the product development activity occurs. Note that the planning activities are spread across the project, instead of big upfront planning, to suit the dynamic nature of the project. Multiple planning iterations help accommodate evolving project details and modify the project plan accordingly so that the final product closely matches customer expectations.

Timeboxing

In this segment, let’s understand about Timeboxing in Agile.

The idea of timeboxing is to set a fixed time limit to an activity. It is a generic principle that can be applied to many aspects of a project. One of the key principles of timeboxing is that the timebox itself cannot be exceeded. Activities that cannot be performed within one timebox, such as completing a user story, are deferred to the next timebox.

Timeboxing is crucial in determining the velocity of the iteration or sprint and drawing estimates for future iterations. In the context of Agile, timeboxing can be extended to:

Timeboxing - Best Practices

Here are some of the best practices in using the timeboxing technique.

First, the timebox can be of any duration, it can be years, months, or days; it can be even minutes like a 15-minute scrum.

Second, control is achieved at the minimum duration of the timebox. If you exceed the 15-minute timebox of the scrum, it delays all the activities that follow for the rest of the day.

Third, if you cannot accomplish everything that was planned to be done within the timebox, you defer it to the next timebox.

And fourth, the length of the iteration is used to determine how much work the team can deliver at that time.

Timeboxing - Advantages

So, what are the advantages of using the timeboxing technique? Timeboxing helps you focus on the task at hand, keeping aside all distractions. Giving a task your undivided attention always improves performance. Timeboxing drives productivity. People tend to work harder and smarter (emphasize) when they know there is a deadline.

Timebox is an effective cure for tendencies such as Parkinson’s Law or the Student’s Syndrome. Refer to the note to understand what Parkinson’s Law or Student Syndrome is. Timeboxing helps you realize how much time was actually spent on a particular activity, leading to better time estimation. Also, the enforced time limit helps you to avoid “analysis paralysis”, that is, spending too much time on analysis.

Estimation

Estimation is a forecast of costs, schedule, effort, or skills required to deliver the intended product. It is necessary to assess the feasibility, Business Case, and Return on Investment or ROI of the project. Although the details available at the start of an Agile project are minimal, ROM estimates would still be required to make informed decisions.

Let us understand some basics of estimation in Agile projects.

Why do you need estimates? Estimates allow the team to size the project and compute ROI and IRR, which form the basis for approvals required to execute the project.

Who performs the estimations? The Agile project team estimates the requirements, based on the inputs from the Product Owner, and the ScrumMaster moderates the estimation.

When is the estimation session conducted? Estimation sessions are conducted throughout the project. As most of the details emerge through progressive elaboration, the team meets at regular intervals to estimate new requirements.

How are estimations created? The team uses techniques, such as Planning Poker or Affinity Mapping, to determine the estimates for the requirements.

Accuracy vs. Precision

Agile estimates strive for accuracy but not precision, as achieving precision makes the estimation process lengthy and expensive. Accuracy means converging on a standard or known value. Whereas precision is about repeatability, that is, to be able to produce the same output again and again, even if that output is not accurate.

In software development, precision is difficult to establish and hence teams focus on creating effort estimates that are accurate rather than precise. Focusing on precise but inaccurate estimates do not serve any purpose to the team or the business.

Measures of Project Size

In traditional sequential projects, the commonly used measures are lines of code (LoC) and function points. In Agile, estimates are expressed as ideal days and story points. Agile story points and the function points used in traditional estimation are considered pure measures of size, as they are unitless. However, LoC and Agile ideal days have their respective units of measurement.

Traditional measures such as function points or LoC do not fit in Agile projects because requirements in Agile are expressed in smaller units called stories. Requirements are evolving and not expressed in as much detail as in traditional projects. Further, Agile believes in lightweight methods even for estimation, giving just enough predictability to plans. Both LoC and function points require much more rigorous analysis, something that is not done in Agile projects.

Relative Sizing

Relative sizing is a technique used widely across Agile in place of the more traditional methods of Top-Down, Analogy, Parametric, and Bottom-Up estimation. As the name implies, the focus is to simply identify how big or small requirements are, compared to a baseline, instead of trying to find absolute values.

In the given example, you can see that by establishing the size of the cup in the middle as Medium, the size of the other cups can be estimated relative to the Medium cup (emphasize). Therefore, the Medium cup becomes the baseline against which other cups are compared and sized. Relative estimation is a kind of approximation and hence not a 100% accurate, however, they are less time-consuming.

Story Points

Let’s understand the Agile Story Points below.

Story Points is the relative unit of measurement expressing the overall size of a user story and its associated effort. Represented as a number, story points reflect how hard it is to implement a user story. ‘Hard’ could mean complexity, the extent of unknowns, or effort. More story points signify the user story is complex and time-consuming and vice versa, fewer points signify less complexity, less effort.

Following the principle of relative estimation, a baseline user story is established, and points are assigned to it. Other user stories are compared to this baseline and given less or more points depending on the anticipated effort relative to the baseline.

Story point estimates are determined by the team using techniques such as Planning Poker or Affinity Estimating, discussed later in the lesson. It is important to note that, story points are unique to each team, and it is not a good idea to compare story point estimations of different teams.

Story Points (contd.)

While assigning story points, consider the size of the task, relative values, and the actual estimation. The size, and hence the story points assigned to a story depends on many factors: The first factor is: “how hard is the story?” Some stories are complex and require deep thinking, exploration, and experimentation to arrive at the correct logic. The next factor is: “How much of it is there?” Some stories may not be complex, but may still involve a lot of effort.

For instance, having to make similar kind of code changes at multiple locations in the mainline. Another question is: “How risky is it?” Some stories impact a sensitive or core area of a product and hence have to be executed with a lot of care. Such stories also have intensive testing requirements. The thing to remember about story point is that it is a relative measure of size, and so the absolute number is not important. Story points make sense only when seen in the context of other user stories. Example, if the ‘search’ user story has eight points assigned to it, and the ‘login screen’ user story has two, the search feature is about four times the size of the login screen feature.

The first step in story point estimation is to select a benchmark and assign it points. For example, the smallest story in the group can be estimated to be worth one story point. Then, a slightly larger story can be assigned five points and considered as a “medium.” Other stories are now compared against these two benchmarks and sized accordingly.

Story Points Estimation - Steps

Let us understand the story point estimation process in detail.

In the first step, break the user stories into smaller functionalities, and ensure each story possesses the INVEST attributes. Ideally, the work associated with each story must not take more than two days to complete.

Second, identify a story that is already worked on and well-understood by the team, and establish it as the baseline.

In the third step, compare the other user stories against this baseline and finalize story points for each using estimation techniques such as Planning Poker or Affinity Estimation.

The fourth step is performed at the end of the iteration when the story points for a user story are calibrated with the actual effort. This helps you understand if the baseline still holds or has changed during the iteration.

Story Point Estimation by Analogy

An effective way of estimating story points is by comparison. Comparing a user story to multiple other stories is based on the premise, “If story A is similar to story B, their estimates are also likely to be similar.” Alternatively, instead of using a gold standard, you can triangulate, that is, establish multiple benchmarks.

When two or three stories of different sizes are set as benchmarks, a possible comparison is: Story A is bigger than Story B, but smaller than Story C. So, if Story C is “Large” and Story B is “Small”, then Story A is likely to be close to “Medium.”

Value Points

Agile emphasizes delivering value and outcomes early and often, and hence there is a need to capture the value associated with each user story. The relative business value delivered by each story is assessed and expressed as points. Value points act as a parallel to story points.

Once you have assessed the value points for each story, you can determine the total value delivered by the project by summing up the points of all the stories. Applying the same relative sizing technique to the values of stories provide insight into overall value delivery. This also engages the Product Owner and business stakeholders in quantifying the value of the stories or features. Value points bring real power to measurements. They also help identify the breakeven point, that is, when the value delivered by the project equals the cost of delivering it.

Ideal Days

An ideal day estimate answers the question— how long would it take to implement a story if it is ALL that you worked on, without any interruptions, and with everything required for the story in terms of clarifications, dependencies available?

Once you arrive at the ideal day estimate, convert it to the actual or elapsed days after accounting for the potential distractions. Incidentally, ideal days are called Perfect Engineering Days in Extreme Programming.

Ideal Days (contd.)

The distractions that have to be accounted for in converting an ideal day estimate to actual days include time for:

Training

Review

Demonstrations

Sickness

Fixing bugs

Email communication

Interviews

Meetings

Phone conversations

The management’s review

Anything that does not directly contribute to the task at hand is considered as a distraction. For example, in a normal workday of eight hours, a developer may spend only about five hours in programming work. Therefore, even if development time is estimated at eight hours or one workday, the actual or elapsed time might be closer to one-and-a-half days.

Story Points and Ideal Days

So, how do these two measures of size, story points and ideal days, compare? Story points help drive cross-functional behavior. As size is measured at the aggregate level, story point estimation does not differentiate between coding, testing, or documentation time. Because they are derived from comparing user stories, story point estimates do not decay with time and are an example of a pure, that is, unit-less measure.

Story point estimation is faster as the human mind handles relative measures better than absolute values. When it comes to ideal days, it is important to remember that they can differ between members of the same team. For example, an experienced developer may have a lower ideal day estimate compared with a junior developer.

Ideal days are easier to explain outside the team than story points, as story points are more abstract. Ideal day estimations are easier, but take more time than story points. Ideal days compel companies to confront time-wasting activities and help the team focus on development activities.

Estimation Scale

Agile estimation aims at reasonably predictable estimates and does not strive for precision. To quickly converge on an accurate estimate, Agile recommends using non-linear scales. Two commonly used non-linear scales are:

The Fibonacci series, in which the succeeding number is the sum of the previous two numbers

Doubles, that is, doubling each number to get the next in the series

Let us look at an example. The baseline user story has a size of 3 story points. During the estimation session, the team comes across a user story they feel is 3 times the baseline user story. Which option will they select? Given that the team has to use a non-linear scale, they can choose from only 5, 8 or 13 story points.

The team would eventually settle for 8 story points, as it is close to 3 times the baseline reference. Selecting 5 story points would be an underestimation, while 13 would be an overestimation of the size of the user story.

Wideband Delphi

Wideband Delphi is a variant of the well-known Delphi technique and is used in effort estimation. This is a consensus-based method, which makes it easier to achieve the estimating group’s buy-in and build their confidence. In this method, the project manager selects a team of experts—people with sufficient knowledge of the solution to be developed—involved in the estimation.

Once the team is selected, estimates are received from each member individually. These estimates are collated and summarized by the project manager and sent to the team. If the estimates vary widely, the team participates in another round of individual estimation. This process is repeated until a consensus is reached.

A major drawback of this Wideband Delphi technique is that it is time-consuming, as it requires a lot more effort to coordinate and collate different estimates through multiple rounds, especially when compared to conventional estimation techniques like expert judgment or estimation by analogy.

Wideband Delphi Process

Broadly, the steps involved in Wideband Delphi are Team Selection, Kick-off Meeting, Individual Preparation, Estimation Session, Assembling Tasks, and Task Review. Let us look at each in detail.

In Team Selection, the project manager chooses the team who will create the estimates and a moderator. This team must be cross-functional, representative of the different groups who will be involved in the development process.

At the Kick-off Meeting, the moderator explains the process to the team and sets the ground rules. The team comes up with a set of assumptions, a high-level Work Breakdown Structure or WBS, and the units for estimation. Following this, team members individually generate their initial estimates for each task in the WBS, and document assumptions they might have missed in the kick-off meeting.

Next, the team participates in an estimation session, which is a series of iterative steps driving them to a consensus. The individual estimates are charted on a whiteboard to understand the range of values and the assumptions or changes each member puts forward. The team resolves its differences and each member revises his or her estimate.

This process repeats until none of the members want to change their estimates and agree on an acceptable degree of variation. This process is timeboxed to ensure the estimation sessions do not drag on endlessly. Next, the project manager collects and compiles the final list of numbers along with the assumptions underlying those estimates.

As the last step, the project manager reviews with the team the results of the estimation process, the final task list, and the assumptions.

Wideband Delphi Technique-Planning Poker

Planning Poker, a variant of Wideband Delphi, is a collaborative session where the entire team estimates the effort involved in each user story. Like Wideband Delphi, it is iterative, and a fun way to arrive at a fairly accurate and quick estimate. In this method, each participating member is given a deck of cards, which are numbered on a non-linear scale.

Example, if the Fibonacci series is being used, you will have cards bearing the numbers 1, 2, 3, 5, 8, 13, and so on. The customer or Product Owner reads out the story card, giving details to the team. The team then discusses the story and asks questions to understand what is required. Next, each team member selects the card that matches their estimate for the story and places the card face-down on the table.

When requested by the ScrumMaster, everyone holds up the numbered card with their estimation, at the same time. Typically, there will be one or more outliers. The team discusses the estimates, especially the outliers, and the rationale behind them to try and reconcile their differences in terms of understanding of the work involved. Following this, the team participates in another round of estimation; this continues until the team arrives at a consensus.

Planning Poker - Example

Let us look at an example of the game of Planning Poker. The Product Owner reads a user story and four team members provide their estimates using the Planning Poker cards.

A sample user story is: “As an insurance agent, I want to create a quote that I can share with the customers.” Ken chose an estimate of three, Mike chose eight, Esther chose two, and Mary picked five in the first round of the estimation. After discussion, they chose five, five, five, and eight respectively in the second round. At this point, the estimates are fairly close. The Product Owner can ask the team if it wants to go with the majority figure, five, or choose the more conservative option, eight.

Affinity Estimation

Affinity Estimation is used to quickly estimate a large number of stories. For instance, it can be used just before release planning or budgeting to arrive at coarse but fairly reliable estimates without taking much time. Apart from being quick, Affinity Estimation allows for fairly transparent decision-making. It creates a positive and collaborative experience rather than a confrontational exercise where people argue about the estimates. The image you see here will be discussed in detail in the following screens.

Affinity Estimation Process

The steps in Affinity Estimation are Silent Relative Sizing, Edit the Wall, Place Items into Relative Sizing Buckets, Product Owner Challenge, and Store the Data.

Affinity Estimation Process—Step 1

In the first step, Silent Relative Sizing, the Product Owner presents the product backlog to the team. Typically, each story, in the form of post-it notes or an index are displayed on a wall. Team members estimate the effort involved in each story and arrange the stories in ascending order horizontally on the wall. The notes can be rearranged until the entire team is more or less satisfied with the order. This step is performed silently, as in mute-mapping, to keep it quick and non-confrontational.

Affinity Estimation Process—Step 2

In the second step, team members discuss with the Product Owner and edit the relative sizes of user stories placed on the wall by moving them in either direction. In the discussion, the team may talk about design, missing items in the product backlog, or any other clarification required from the Product Owner. This continues until the team is satisfied with