A Complete Guide To Agile Project Management (APM)

This Comprehensive Tutorial on Agile Project Management Methodology Explains the APM Framework, Release Planning, Risk Management, Metrics with Examples & Graphics:

What is Agile Project Management?

Agile Project Management is an interactive process for managing projects. In this process, a project is divided into small sections or tasks. these tasks are completed in small iterations.

This approach to Project Management requires continuous improvement and constant collaboration among project team members.

Agile Project Management Methodology

Agile Manifesto: Principle 1

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

The below points define the Principle clearly:

• Deliver valuable software to the customer.
• Value is measured by the customer in terms of Profit, Cost savings or Market capitalization.
• Budget, schedule, and scope act as a constraint on the system.

Why Agile Works?

Agile methodologies are used in the projects because of their prominent features.

The features include:

• It delivers business value regularly and incrementally.
• It provides visibility to the business throughout the project.
• Reduces delivery risk steadily throughout the project.
• Maintains adaptability to business changes as long as possible.

Agile Project Management (APM) Framework

Agile Project Management or APM Framework was introduced by Mr. Jim Highsmith in the book, Agile Project Management – Creating innovative products. Traditional project manager focuses on following the plan with minimal changes, whereas an agile leader focuses on adapting successfully to the inevitable changes.

The APM Framework

Product Vision

The Product Owner establishes the Vision for the project and ensures that all the stakeholders have a common vision for the project. A good Product Vision remains relatively constant, whereas the path to implement the vision needs room to wander.

Exercising Product Vision Box will help the product teams to create a visual image of the product.

An Elevator Statement is a short summary that used to quickly and simply define a Product, Service organization, and Value proposition. An elevator pitch is often used by an entrepreneur pitching an idea to venture capital to range investors to receive funding.

Elevator Statement Format

Product Backlog

It defines the prioritized list of the outstanding work that is necessary to bring the product to life. Each Product Backlog Item(PBI) is written in a user story format.

DEEP Qualities of Product Backlog:

• Detailed appropriately
  • Higher-priority items are described in detail than the lower-priority ones.
• Estimated
  • Estimated using story points
• Emergent
  • It evolves. Add/Update/Delete items as appropriate. Anyone can add items to the backlog.
• Prioritized
  • Product Backlog work items are prioritized. Most important items with the highest priority are implemented first.
  • These high priority items are listed topmost in the Product Backlog list. Only the Product Owner prioritizes the product backlog.

Product Roadmap

The Product Roadmap shows the planned releases and relevant features. It is owned by the Product Owner and serves as a high-level overview of the product requirements. It is used as a tool for Prioritizing features, Organizing features into categories, and Assigning rough time-frames.

Creating a Product Roadmap has four basic steps as shown below:

• Identify Requirements (These will become a part of the Product Backlog).
• Organize Requirements into categories or themes.
• Estimate relative work effort (For Example, planning poker or affinity estimation), and prioritize (value).
• Estimate rough timeframes (Estimate velocity, sprint duration, and rough release dates).

The Story Mapping technique is used during Release Planning to visualize the backlog. This advantage helps to identify the flow and gaps in backlogs.

Product Roadmap vs. Product Backlog

As the Roadmap takes care of the strategic product planning aspects, it frees the backlog to focus on the tactical work.

Release Planning

Planning Levels

Most of the Agile teams are concerned only with the three innermost levels:

1. Release Planning
2. Iteration Planning
3. Daily Planning

Release Planning

Release Planning is about making scope, date, and budget trade-offs for incremental deliveries as well as onboard teams before the start of a release. Release plans are not commitments, rather they are guideposts.  The Agile manager will communicate the release plan to all the stakeholders for their consensus.

• Date Driven(Timeboxed): Released by a certain date for which the feature set is negotiable.
• Feature Driven(Scopeboxed): Completion of a set of features are considered to be more important, the schedule is negotiable. For Example, if you are launching a product for the first time in the market.

Estimation Techniques

Estimating the effort involved in a user story is done by the team that will be committing to deliver it, and only that team.

• Story points are a relative measure of the size of a user story.
• An ideal day is a time that it would take to complete a task and there should be no interruptions. For example, A football match lasts 90 ideal minutes but the elapsed time it takes is more than 90 minutes.
• The Agile/Scrum estimation technique uses relative estimation and it is a game invented by James Grenning and popularized by Mike Cohn called the Planning Poker.
• Non-linear sequences work well because as reflect greater uncertainty associated with estimates for larger units of work.
• The industry-wide accepted point system that is utilized for these values is Mike Cohn’s modified Fibonacci sequence: ½,1,2,3,5,8,13,20,40,100,? (infinity)

When to Play Planning Poker?

• After the initial Product Backlog is compiled.
• Subsequently whenever a new PBI is added to the backlog.

Flow of a typical Planning Poker Cycle:

Factors to be considered while Sizing Stories:

• Complexity (Difficulty level, For Example, Designing an algorithm)
• Uncertainty (Unknown technology or domain)
• Effort (how much)

Prioritization Techniques

Prioritization techniques include:

1. Kano Model
2. MoSCoW

Product Owner prioritizes the Product Backlog.

Factors to consider while prioritizing features are:

• The amount and significance of learning and new knowledge created by developing the features.
• The amount of risk removed by developing the features.
• The financial value (benefit) of having the features.
• The cost of developing (i.e. perhaps supporting) the new features.

#1) Kano Model

Kano Model Diagram:

Product Owner will prioritize requirements with a written questionnaire to selected stakeholders.

#2) MoSCoW

Here, in the word MoSCoW, the capital letters are defined as shown below:

• MUST(M) have these fundamental features.
• SHOULD(S) have the features that are important but there’s a short-term workaround for them. Considered mandatory if no time constraint.
• COULD(C) have this if it does not affect anything else.
• WON’T(W) have this time but would like in the future. This is desired but acknowledged as required to come in a later release.

MoSCoW approach, from DSDM, is based on the 80/20 rule, in which 80% of the benefit of a system will be derived only from 20 percent of the system requirements.

Iteration Length

Length of an Iteration depends upon:

• Length of release being worked on.
• Amount of uncertainty.
• Ease of getting feedback.
• How long the priorities remain unchanged.
• Overhead of Iterating. For Example, Each iteration must be fully regression tested.
• While defining the length of the Iterations, the team should consider how it will deliver valuable chunks of product functionality, the definition and development of user stories, and the acceptance of user stories by the customers.
• There’s no magic iteration duration that is right for all the teams under all circumstances. The right iteration length for a team on one project may not be the right length for the same team on a different project.
• Have 4 to 5 iterations in a release and it will give you an opportunity to inspect and adapt.
• For high uncertainty projects, it is suggested to follow small iteration lengths.

Estimating Initial Velocity

Velocity is a measure of the number of user story points or stories completed by a team per iteration.

Backlog Grooming

Grooming refers to a set of three principal activities i.e. Creating and Refining (adding details to) PBIs, Estimating PBIs, and Prioritizing. Grooming is a collaborative process. Items are discovered, described, prioritized, decomposed, and refined by the entire team.

When to perform Grooming:

• Initial: Before release planning or as a part of the Release-planning activity.
• Ongoing: During each sprint (Scrum allocates up to 10% of the team’s availability for the grooming activities).

Release Planning Example

Velocity = 20 Story Points per iteration
Backlog size = 500 Story Points
Iteration length =2 weeks

DateDriven (Timeboxed) – Release duration 3 months.

# of story points we can complete in a release = velocity * # of iterations = 20*6 = 120 story points

FeatureDriven (Scopeboxed) – 200 story point to complete in a release.

Duration of release (# of iterations in a release) = # of story points in a release/velocity = 200/20 = 10 iterations = 20 weeks.

Risk Management

Risks are anti-value. Risk management plans to deliver high business value features early, plan to execute risk avoidance and risk mitigation activities early too.

There are:

• 5 core risks (as stated by Tom DeMarco and Tim Lister).
• Risk-adjusted Product Backlog.
• Risk-based Spike

Core Risks Addressed By Agile Framework

In Waltzing with Bears book on software Risk Management, Tom DeMarco and Tim Lister have identified five core risks that dominate software projects.

Risk Value Relationship

• The high-value, high-risk features should be developed first. These features deliver the most value, and working on them eliminates significant risks.
• Next is, the high-value, low-risk features. These features offer as much value as the first set, but they are less risky. Therefore, they can be done later in the schedule.

A feature’s risk and value profile change over time. A low-value, low-risk feature in the Avoid
quadrant today could be in the Do first quadrant six months from now if all the other features have been finished.

Risk-Adjusted Backlog

Risk-Adjusted Backlog is a blend of value-generating business features and risk-reduction actions. Risk-Adjusted Backlog focuses on where investment needs to be undertaken, based on the risk.

Steps to create Risk-Adjusted Backlog:

• Allocate dollar value to feature based on ROI and prioritize the list.
• Allocate monetary value to the risks identified based on probability and impact. Rank the project risks to produce a prioritized Risk List, ordered by Risk Severity.
• Combine the prioritized feature list and risk actions based on value. The prioritized list is a Risk-Adjusted backlog.

Risk-Based Spike

A Spike solution, or Spike, is a technical investigation. It’s a small experiment to research the answer to a problem. A Risked-based Spike is a task that is used to gain knowledge in an area of uncertainty to reduce risk.

Spikes may be used for a number of reasons:

• For basic research to familiarize the team with a new technology or domain.
• It can help split the story into estimable pieces.
• Iteration Slack absorbs the spikes which take few minutes. If you anticipate the need for a spike while estimating a story, then include the time in your story estimate. Sometimes, you won’t be able to estimate a story at all until you’ve done your research, in this case, create a spike story and estimate that instead.
• The purpose of a Spike solution is to give you the information and experience to know how to solve a problem, and not to produce the code that solves it.

Metrics

• Leading Metrics: They are the ones that help us to extrapolate from the series and determine what happens next. Trends in project data are useful as they can offer insights. For Example, Prediction of features to be completed in a release based on velocity trends.
• Lagging Metrics: Helps to take corrective actions.

Metrics are of the following types:

1. Velocity
2. Burndown bar chart
3. Risk-Adjusted burn-up chart
4. Running Tested Features(RTF)
5. Cumulative Flow Diagrams(CFDs)
6. Parking Lot Diagrams
7. Earned Value Management(EVM)

#1) Velocity

Velocity Metrics can be defined as shown below:

• Sum of the sizes of all completed backlog items in an iteration.
• The amount of work the team has done in an iteration i.e. the amount of work is reflected by the size of work.
• It is comparable across iterations for a given team on a given project.
• Is not comparable across teams and across projects.
• Pair programming has no impact on story point estimates, it only affects team velocity.

Velocity can best be improved

• Closer involvement of the customer.
• Technical Excellency
• Continuous integration without Technical Debt.

Velocity Usage:

• Release planning to identify the release date.
• As diagnostic metrics in retrospective trends help.

#2) Burndown Bar Graph

• Lower the top of the bar when tasks are completed.
• Lower the bottom of the bar (below the baseline) when tasks are added to the initial set.
• Raise the bottom of the bar when tasks are removed from the original set.
• Raise or lower the top of the bar when the amount of work involved in a task changes.

Progress is shown above the baseline and change in scope is shown below the baseline in the graph.

#3) Risk-Adjusted Burn-up Chart

Risk-Based Burn-up chart tracks targeted and actual product delivery progress and also includes estimates of how likely the team is to achieve the targeted value adjusted for risk.

Risk-Adjusted Burn-up shows how the risks evolve over time. It gives more insights into the current state of the project and visualizes the risk of successful project completion. It helps conversation with the stakeholders as it expresses the problem in scope and not in time.

risk_adjusted_points_remaining = (iterations_remaining-risk_exposure)*velocity/ risk_multiplier

The color gradient between green, orange and red represent the Risk in the above chart.

Risk multipliers are dependent on the organization or we can use generic multipliers like the one provided by DeMarco.

#4) Running Tested Features (RTF)

• For each named feature, there are one or more automated acceptance tests that, when they work, will show that the feature in question is implemented.
• The RTF metric shows, at every moment in the project, how many features are passing all their acceptance tests.
• Running Tested Features should start showing up in the first week or two of the project, and should be produced in a steady stream from that day forward. Wide swings in the number of features produced (typically downward) are the reasons to look further into the project to see what is wrong.
• Tools like FitNesse will help to measure the RTF metric.

#5) Cumulative Flow Diagram (CFD)

• Cumulative Flow Diagram (CFD) conveys the progress of the entire backlog.
• Burn-up charts can be converted to Cumulative Flow Diagrams by the addition of Work In Progress (WIP).
• Cumulative Flow Diagrams can be used to track Work In Progress and identify the bottlenecks without the need for micro-management.
• The widening band is the feeding activity and not the problem activity, the activity below the widening activity is the bottleneck activity.
• Queue size is a useful leading metric that can help us determine the likely completion times.

Agile methods inherently reduce the likelihood of activity-based bottlenecks by promoting multi-disciplined teams.

#6) Parking Lot Diagrams

Parking Lot Diagrams are a nice way of summarizing progress against a variety of goals in a single page executive summary. Colour coding helps the highlighted areas behind (red), done (green), in progress (yellow), and not yet started (white).

#7) Earned Value Management (EVM)

• Earned Value Metrics track the progress against the plan and they do not track Earned Business Value.
• Defining the initial Release Baseline:
  • # of planned sprints in a release.
  • Sprint lengths
  • Budget at completion.
  • # of story points planned for the release.
  • Start date of the project.
• Measuring progress (data points required):
  • Story points completed to date.
  • Story points added to date (can be–ve number).
  • Actual cost
  • Current sprint
• % complete = 0% or 100% complete rule for a user story.
• Each sprint boundary was established as the ‘measuring point’ to re-baseline any changes and re-evaluate the earned value results.

Conclusion

Agile project management is an iterative approach to managing software development projects that focus on continuous releases and incorporating customer feedback with every iteration.

Also read =>> What is a RACI Matrix

There are some disadvantages of Agile Project Management as mentioned below:

• Identification of project risks is not easy.
• Inefficient management of resources.
• Some project teams don’t know how to use agile project management efficiently.

However, with the surging development of business and technology across the world, many projects teams need to ensure that they meet the client requirements in a timely manner instead of wasting efforts in refining requirements that may become outed by the time the end-product is delivered.

Thus, finding the right balance to deliver a quality product within the specified time is the key to successful project management using Agile methodology.

Further reading =>> Complete Guide to Project Management Office