Importance of adaptive planning in Agile

1. Importance of Adaptive Planning
By Sangeetha Siddhantam PMP, PMI-ACP

2. Organizations encourage adaptive planning for projects. Planning to re-
plan is a successful way to achieve project goals. Changes are inevitable in
projects and responding to these changes is important. Accommodating
changing requirements throughout the development process is a key
principle of agile. Adaptive planning enables us to manage these changes
effectively. Doing necessary adaptive planning not only minimizes waste
but delivers maximum business value.
As a result of adaptive planning, organizations are not only able to
continuously increase their business value, reduce risk, adapt to changing
requirements but also achieve high visibility to project progress.

3. Let’s quickly glance at differences between agile and non-agile (traditional) planning.
While traditional planning is a linear approach, agile is iterative and a team-based approach.
Upfront planning is emphasized in traditional planning. This can lead to problems as we
gradually progress in projects. Whereas in agile, planning is iterative and progressive.
To reflect planning and risks associated with both agile and non-agile methodologies, Boehm
came up with a term “planning sweet spot”. To avoid losses incurred due to inadequate
planning and market share erosion, Boehm suggested that we aim for “sweet spot planning”, by
planning just enough to minimize any risk and rework.
Agile teams strive for customer feedback by demos and working prototypes. If they fail to get
customer acceptance, they re-plan their strategy midcourse by making adjustments to the
iteration till they get business approval. From this, we can say that midcourse adjustments are
normal in agile.

4. Principles of Agile Planning

5. There are 9 high level principles for agile planning:
• Agile focuses on planning at multiple levels. The amount of details addressed at each level results in delivering
continuously a high value product.
• For a project to be successful , two-way communication is very important. Both team members and customers should
be engaged in planning. Customers should be available for the trade-off, demos, and feedback on the deliverables.
• Being transparent is a key aspect of Agile. Frequent demonstration of progress keeps stakeholders updated on project
status.
• Uncertainty is very high in large or complex projects. Prescribing one process to the entire project does not fit
project’s purpose as teams and requirements are different at different phases of the project. Agile tailors the process
to fit different natures of the project by minimizing uncertainties, risk and rework.
• Agile backlog makes release and iteration planning easier. The product owner should see how changes influence
backlog and release plans. Depending on projects priorities, plans should be be updated continuously.
• Estimating a project should not be limited to the schedule and cost of the project. Always look at other risks such as
the velocity trends of the team, their availability, any distractions, diversions that can occur inevitably. Also factor in
the availability of skilled resources in due course of the project. Not having skilled resources when required can
throw the entire project off the track.
• Use estimate ranges to factor-in uncertainties.
• Project projection on completion data should be based on the actual or real progress of the project rather than a plan
based on theory.
• While estimating, factor in all the possibilities of the resources ideal time, unproductive time, and their absences so
that the project can handle unforeseen circumstances.

6. Agile Discovery in Adaptive Planning
Agile Discovery in Adaptive Planning: Contrast to traditional project planning agile project plans evolve over a period of time. This
evolution of agile project plan is referred as agile discovery. Agile discovery is the process of gathering information on what the
customer requires and making informed recommendations that are critical at the very beginning of project.
Progressive elaboration in action
New information incorporated into project plans and continuous update of project plans as we progress into the project is called
progressive elaboration. As the project progress the details not only become more specific and accurate, but also the changes are
updated in each successive iterations. The key benefit of Progressive Elaboration in Agile, is that teams spend maximum amount of
time on high-priority features and minimum amount of time on low-priority features.
Let’s see progressive elaboration in action:
1. Fractal leaf pattern
Throughout the project we are continuously identifying new requirements, grouping them and prioritizing their features
accordingly, and they are refined as more details become available similar to a fractal leaf pattern. The ultimate goal is to
deliver a highly detailed product by end of the project.
2. Coarse grained requirement
In agile, detailed planning is never encouraged. The requirements are coarsely grained and refined as the project
progresses so that changes are incorporated continuously resulting in reducing risk, increasing productivity and getting
early feedback from customers.
Rolling wave planning: Progressive elaboration should not be confused with rolling wave planning. In rolling wave planning, detailed
project planning is done for high priority features, items or activities and only high level planning for low priority items that are in
future.

7. Process of Assessing:
Value-based Analysis & Value-based Decomposition

8. Value-based analysis is a management strategy used to determine changes in
value with concerning to quality and cost. Lately, organizations want to
produce products quickly with less cost than delivering a one-time high-
value product. By releasing a low-value product, we can see the product
behavior and determine how we can strengthen the product by its
competitiveness in the market.
Value-based decomposition is an extension of value-based analysis. In this
process, a low-value product is sliced further keeping in mind to produce a
value-driven product to the customer. Value-based decomposition ensures
that customer is satisfied at all levels.

9. Agile Concept of Timeboxing

10. Timebox: A timebox refers to a period during which the team agrees to complete an item or activity
of a project. Any uncompleted work is moved to the next period or into another timebox and waits
for subsequent iterations. The goal of timeboxing is to limit the time dedicated to a particular item or
activity. In the previous slide we discussed value-based analysis, where at times a high-value item is
dependent on a low-value item. If we can manage to deliver low-value items on time, then delivering
high-business-value items is assured. Timeboxing focuses on delivering low-value items frequently
and tracks how the project is progressing in actual.
You can also refer to my previous Slideshare “Introduction to Agile” for timeboxing in Scrum and
the DSDM prioritization technique Moscow. While delivering the low-level items, the “must have”
items also need to be identified. The delivery process can be continuously reassessed by prioritizing
the low-level items with Moscow and by timeboxing the item. Timeboxing was developed by DSDM
consortium by its founders in 1990.
Agile project management traded the traditional triangle of constraints for the inverted triangle
model. By keeping time and cost fixed, the team can adjust the scope through multiple iterations.
This is another variation of time-boxing.

11. Estimate Ranges in Agile

12. For any knowledge work projects, uncertainty and complexity are very high, making the estimation
process difficult. Similar to traditional estimation, agile can use either expert knowledge based
(heuristic) or parametric estimates in which calculations are based on numbers and complexity of
user stories. When estimating in agile, the key things to consider are why and what is being
estimated, and who are involved in the estimation process.
Close range estimates are used for smaller sized projects with certainty. Wide range estimates are
used for larger complex projects with uncertainty. Barry Boehm’s concept of “Cone of
Uncertainty” describes that uncertainty is very high during the initial phase of the project, and
decreases gradually as the project progresses. Similar to this phenomenon, estimate ranges are
initially very broad due to uncertainty and narrows down as specifications and scope become clear
through the progression of the project.
In estimating ranges for the project, the following three types of resources are involved:
The product owner gives the requirements to the team. The team comes up with ideal time
estimates to complete the project uninterrupted while removing all distractions and diversions. The
agile coach is involved in facilitating the meetings, and is also one of the key members involved in
estimating.

13. Basic structure for an Agile Requirements:
Feature, User Stories, and Task

14. From my experience as a Project Manager, it is significant to know how and why sizing affects
projects. Accurate estimation of the size and scope will lead to effective planning and successful
execution of the project. A large and complex project can be sliced into smaller parts or, in other
words, decomposed. The smaller/decomposed parts get refined and reassessed till they become
the actual requirement.
The basic structure of agile requirements would include:
• Features
• User stories (will be discussed in detail later on)
• Tasks
Features would have business value and priorities.
User stories provide short and simple description of features to be built in the project by agile
teams and are typically written on index cards. (Ah ha now we have index cards so what are we
going to do with them? Interestingly there are three things known as three c’s that user stories
capture.)

15. The Three C’s of user stories:
Card- Team members, along with the help of the product owner, write a detailed, single, compact
sentence on these cards. These stories are written so that they can be tested and accepted by the
customer. The product owner prioritizes user stories in the backlog using team inputs.
Conversation- The agile manifesto encourages face-to-face conversations, during which ideas and
opinions are exchanged during the story writing process.
Confirmation- The customer approves that the user story has been completed according to the agreed
acceptance criteria set beforehand.
Since we are diving into user stories, I would like to share some key characteristics of user stories. Bill
Wakes created a mnemonic called INVEST. Let us break down each component here.
I- Independent User stories are created independently and selected on merit.
N- Negotiable Team should be able to negotiate user stories with the product owner.
V-Valuable User stories should have value or benefit to the customer.
E- Estimable User stories should be good enough to be estimated so that they are properly
prioritized.
S-Small User stories that are small are easy for estimating and testing.
T-Testable Acceptance tests are written on the back of user story cards. Writing the test early
helps to know if the goals are met.

16. Since we are talking about user stories, Lets quickly go over user story backlogs (also known as product
backlog) and refining backlogs (also know as backlog grooming).
A user story backlog or product backlog is a list of user stories that need to be prioritized and completed in
the project after user stories are created. The product owner is responsible for creating and maintaining the
product backlog. According to the principals behind the agile manifesto, changes are welcome even late
into the project. As the project progresses, product backlog is continuously updated with new information
for the new and changed requirements. The process of re-organization and re-prioritization of the backlog
is called as refining or grooming the backlog. During backlog refining, either new stories are added and
prioritized, or some of the existing stories are removed, or existing user stories are sliced into smaller
chunks.

17. I get it, we talked enough about user stories. BUT, please remember we are still discussing the
basic Agile features of Task.
Task- As the user stories are decomposed, the team works on completing these stories. When
teams are working on a task they are working with specific scope with a specific timeframe. This
is one of the reasons why tasks often follow the SMART acronym :
 S-Specific The task should be simple and specific, making sure everyone involved
understands what needs to be accomplished in each iteration.
 M-Measurable The team must determine how a completed task is measured; in other
words, when the task can be determined as “done”.
 A-Achievable Task is realistic and achievable.
 R-Relevant Every task must be relevant and contribute to the story.
 T-Time-boxed Task should be limited to a specific duration, or timebox.

18. Guidelines for Estimating User Stories

19. Lets quickly go through story points and relative sizing before moving further into guidelines for
estimating user stories.
Story Point- The assignment of a number representing the effort to a user story depending on the
difficulty level of the respective user story.
Relative Sizing- Agile teams always compare the user stories they want to estimate with some
previously estimated stories (known as triangulation). To estimate more effectively, teams rely on
relative sizing. Relative sizing allows teams to make useful estimates to predict the approximate
time it takes for each user story.
Guidelines
1. The team should create and own the definition of story points
2. Story point estimates should be all-inclusive (include risk, velocity, and complexity)
3. Story point sizes should be relative
4. When disaggregating estimates, the totals does not have to match
Story point estimating typically uses the Fibonacci sequence, the sequence of adding the previous
two numbers together; e.g. 0+1=1, 1+1=2, 1+2=3, 2+3=5, etc.

20. High-Level Estimating Tools
Affinity Estimating
T-Shirt Sizing
Story Maps
Road Maps

21. Affinity estimating- A technique where similar stories are grouped and are assigned either a value
or number creating a scale.
T-shirt sizing- User stories are compared and broken into different sizes like extra large, large,
small and extra small. T-shirt estimating is done during the initial stages of the project, updated
continuously throughout the project and practices relative sizing (refer to a previous slide for
relative sizing).
Story maps- A story map is a high-level agile planning tool with an end to end view. A user story
map is a collaborative practice that guides the agile team in creating product backlog. Story maps
not only are an effective and useful tool for capturing requirements but also makes it easier to
work on user stories as the teams are on the same page right from the initial project
stage. Because of high visualization, teams can identify any missing puzzles in the project. Story
maps help avoid waste and prioritize what minimally needs to be built. Story maps also improve
communication not only within the teams, stakeholders, customers but also with everyone
involved in the project.
Product Roadmap- Is a high-level effective tool to show the evolution of the product as the
project progresses. Product roadmap provides stakeholders an idea of how the product would look
and how much it would cost to develop the product. Typically product roadmap consists of one or
more story maps, showing what will be delivered in each release.

22. Tools for estimating user stories
• Wide band Delphi
• Planning Poker

23. Wide band Delphi- A group of experts participating anonymously submitting
estimates is known as Wide band Delphi. Wideband Delphi is a consensus based
estimation technique for estimating effort. It reflects agile values because it is
iterative, adaptive and collaborative in nature.
Planning poker- Like Wideband Delphi, planning poker is also a consensus
based estimating tool. Planning poker provides more accurate estimates than any
other techniques. Planning poker uses playing cards where values are based on
the Fibonacci sequence. These values can be user story points or any unit that
the team wants to estimate. Product owner and team discuss what needs to be
estimated and when the facilitator reads out a problem aloud all the team
members puts a card face down on the table. Cards are revealed at the same time
and the team discusses the difference. They continue to play this game till
everyone reaches consensus on reasonable estimates so the project can keep
moving forward.

24. Release plan
Different types of iteration:
Iteration 0
Development iterations
Iteration H, (also known as hardening spirt or release sprint)

25. A quick synopsis of Release planning
Release plan is a design (e.g. high level draft) for the entire project. Release plan usually has
more than one release in a year depending on the complexity of the project. Release plan is a
plan that is created to deliver completed valuable product incrementally. Release plans in agile
projects have fixed time and each release typically includes multiple iterations.
Since release plan is a high level design, iteration plans are created for capture details of he
plan. During Iteration planning, the team selects the user stories with high priority to be
developed in each iteration. Each iteration is typically lasts from a week to three weeks
depending on the velocity of the team. Release plan is frequently refined. Remember? Agile
can handle changes late in the development.

26. Different types of Iterations
Iteration 0- Iteration 0 in general is about ensuring that we have all the necessary things for the project to
start. Iteration 0 is short and outlines the deliverables. During Iteration 0, the team creates its
first wireframes, the requirements are in a preliminary stage, and the team discusses requirements
internally, and with the intended users.
Development Iterations- Development iterations enable slicing of large requirements into smaller
chunks to continuously and frequently deliver a high value driven product. One of the key advantages
of multiple iterations is, once the iteration work is delivered with acceptance from everyone including
customer, stakeholders will not be revisited.
Iteration H (also known as hardening spirt or release sprint)- The iteration before release, where team
focuses on testing and repairing any defects that they find during the development iterations is known as
Iteration H (also known as hardening spirt or release sprint). In other words, this is a wrap-up iteration
ensuring when the product is released it will go through all additional testing and is ready to be launched
successfully.

27. Spikes:
• Architectural
• Risk based
• Fast failure

28. Spikes- So far we know that agile includes many activities that are time-boxed. Activities that
involve researching a time-boxed effort of a particular item and any risk involved with it or any
other details that would be useful in making a successful high-value deliverable is known as a
spike. It sets a stage for initial development effort and is used widely to investigate any issues at
any given time.
We now know that spike is a research activity. Time-boxed effort where the team hopes that the
research activity done is good enough for the project approach is known as an architectural
spike. The deliverable at the end of an architectural spike is knowledge gained and preserved either
as a document or a presentation.
The time-boxed research activity conducted to either reduce or eliminate risk is known as risk
based spike. These spikes are used to test unfamiliarity before proceeding with the development.
Fast failure- During architectural spike or risk-based spike, it is proven that the approach taken is
not successful. This is known as fast failure. Agile encourages failing fast because it gives a chance
to see where the errors occurred and how not to repeat them again. Like the saying goes “failure is
one step closure to success”, by failing fast we learn fast not to repeat the same mistake.

29. • High Level Planning (Visioning)
• Release Planning
• Iteration Planning

30. Planning with Agile narrows down to three simple questions: What, When and How?
High-level planning: Every product that needs to be developed needs a vision. High-level planning takes place before the
first release of the project and involves product owner, sponsor, a key member of the delivery team and stakeholders
roughly estimating the project by sizing and identifying the product features and user stories. High-level planning removes
uncertainties and provides an updated backlog of user stories and how to respond to risk. It also provides relative estimates
of each user story, deliverables and tentative dates for release planning.
Release planning is a collaborative effort of everyone (including product owner, scrum master, stakeholders, and team)
involved in the project understanding and committing to deliver the agreed release by the agreed date. The purpose of
release planning is to define the contents of a release or a specific shippable product increment. It serves as a guideline that
reflects expectations about which features will be implemented and when they will be completed. Some of the key activities
involved in release planning are selecting user stories, conditions of satisfaction (goals for the schedule, scope, resources),
team velocity and slicing of user stories. Release management metrics are clear across the organization. By enforcing
standards and best practices, release planning ensures delivering smoother transitions of release from development
activities (projects) to final destination environment by increasing productivity and collaboration but also mitigates release
failure.
Iteration planning is highly detailed planning where team members determine how many user stories they can complete and
deliver during an upcoming iteration. The purpose of iteration planning is to organize the work and define the realistic
scope. Iteration planning requires updated backlog prioritized by the product owner and includes discussing and selecting
the user stories in the backlog, writing the acceptance tests for these user stories, and breaking and estimating these user
stories are some of the activities to be accomplished.

31. As a Project Manager, I was extensively involved in the planning stage of all the projects I’ve worked
on. Irrespective of the industry domain the project belongs to such as Information Technology,
Healthcare, Construction, and Pharmaceutical; each project has its own challenges. By planning
adaptively, I was quite successful in removing uncertainties, mitigating risk and avoiding rework. If
you have any questions regarding adaptive planning, please send me an email to san.sidd@yahoo.com.