Agile 

Project Management
 Agile History
• In the early 1990s, as PC computing began to proliferate in the enterprise, software development faced a
crisis. At the time, it was widely referred to as "the application development crisis," or "application delivery
lag." Industry experts estimated that the time between a validated business need and an actual application
in production was about three years.
• The problem was, businesses moved faster than that, even 25 years ago. Within the space of three years,
requirements, systems, and even entire businesses were likely to change. That meant that many projects
ended up being cancelled partway through, and many of those that were completed didn't meet all the
business's current needs, even if the project's original objectives were met.
• It all started in the spring of 2000, when a group of 17 software developers, including Martin Fowler, Jim 
Highsmith, Jon Kern, Jeff Sutherland, Ken Schwaber, and Bob Martin met in Oregon to discuss how they 
could speed up development times in order bring new software to market faster. They recognized two key 
opportunities that achieving this goal would make possible:
1. Shortening the delay of benefits to users in order to resolve the product‐market fit and 
development graveyard problems
2. Getting feedback from users quickly to confirm the usefulness of new software and continue to 
improve on it accordingly.
 Agile is a project management‐ Definition 
The concept provides project managers with a more flexible and efficient way
to get products to market faster. The meaning of agile is the ability to move
quickly and easily. Therefore, an Agile approach enables project teams to
adapt faster and easier compared to other project methodologies.

Mainly used for Development projects encouraging experimentation

Agile Manifesto
https://agilemanifesto.org/principles.html
Agile Manifesto‐ How many Follow these in Spirit?
Waterfall Model Vs Agile Model
When can I choose the waterfall process model over 
agile methods?
one should choose to use the waterfall model only when 
the requirements are well understood and unlikely to 
change radically during system development
Why is Agile preferred Over traditional PM
• More flexibility:  focuses more on the product than following a rigid structure. 
Unlike the traditional approach, agile methodology isn’t linear or follows a top‐down 
approach.

• Transparency: Between the clients, decision makers and team from start to end 
hence develop a healthy work environment.

• Ownership and accountability: Every team member shares ownership of the 
project.

• Scope of feedback : allows constant feedback that is helpful in providing better 
results with reduced time and cost overrun

• Project Complexity: Agile could be your best bet in terms of managing big and 
complex projects.
This is done for proper planning, management : 
These techniques helps in estimating the total efforts that we are going to use for 
implementing, testing and delivering the desired product to the Customers in terms of time 
within the specified deadlines.
 USER STORY IN AGILE
An user story is an informal, natural language description of one or more features of a software
system. User stories are often written from the perspective of an end user or user of a system
 The user story describes the type of user (Who), what they want and why.
 Units in Software estimation
In order for the team to commit to the deadlines, it is important for
the team to come together and provide a realistic estimate.

• The units of estimation can be in hours, days or story points.

• Story points are used as a measure of complexity and unknowns

associated with a task.

• Story point value is calculated according to a calculated baseline. This

baseline is established by the team itself based on the velocity of the
team in past projects.

• Higher the story point value, more effort is required to implement a

particular task.
 THREE MAIN LEVELS OF 
AGILE ESTIMATION
1) Project or Proposal level: Uses Quick Function Point Analysis during the 
initial phases of the Project development.

2) Release Level: includes assigning the story points to the user stories that can help 
in defining the order of the user stories based on the priority (i.e. which to do  in current 
release and which can be taken later).

3) Sprint Level: The user stories are broken into the tasks, and estimated hours are 

assigned to the tasks according to their complexity. Here, we also define the person 
responsible for the task along with the status of the tasks.
 Story point estimation in agile

is a comparative analysis to roughly estimate the product backlog

items with relative sizing.

The team members for estimating user stories include: Product

Owner, Scrum Master, Developers, Testers and Stake holders.
Overview of Some software Estimation Techniques
1) Large/Uncertain/Small ( or BUS‐ Small‐Big‐Uncertain)

2) T‐Shirt Sizes

3) The Bucket System (Fibonacci Sequencing)

4) Affinity Mapping

5) Planning Poker

6) Ordering Method
 Large/Uncertain/Small 
( or BUS Big‐ Uncertain‐ Small)

• Each User story is compared to the other and assigned to any one of the
group (similar to bucket).
• Big or small stories in terms of complexity
• Uncertain stories need to be groomed and broken up (as far as possible)
• Used by companies just moving to Agile
 T – Shirting
(Provides consistent estimation)
The Bucket System (Fibonacci Sequencing)
Each estimator will estimate their own story point and most voted story
point will be assigned to the user story.
Complexity level: By Small, Low, Medium, High
 Affinity Mapping

A good technique when the team is small and no. of backlog

items is less
Planning poker
Compare Sprint with Work Packages (WP) or Group of Work Packages
It is output‐oriented and:
• Defines work (what)
• Helps identify time to complete a task of WP (how long)
• Identifies a time‐phased budget to complete a WP (cost)
• Identifies resources needed to complete a WP (how much)
• Identifies a single person responsible for units of work (who)

Is it Similar to Sprints in Agile?
Function Point methods for s/w and systems projects

Total adjusted count provides the basis for estimating the labor
effort and cost for the project)
AGILE METHODOLOGY: SCRUM PROCESS
 CEREMONIES AND EVENTS IN SCRUM

• Sprint planning meeting
• Daily stand‐up meeting
• Sprint review meeting
• Sprint retrospective
TEAM VELOCITY
 Burn up Chart Vs Burn Down chart
A burn up chart, tracks progress towards a projects completion.
1. A total work line (the project scope line)
2. A work completed line

Burndown Chart

Burnup Chart
Collaborative (Hybrid Agile i.e. Waterfall + Agile)
AGILE METHODOLOGY: KANBAN PROCESS
Basic Philosophy: 
Stop Starting and Start Finishing

Kanban: 
• Provides early and consistent value
• Collaborative and self managing teams
 KANBAN PROCESS – 4 Core Principles

• Principle 1: Start With What You Do Now;
• Principle 2: Agree to Pursue Incremental, Evolutionary Change;
• Principle 3: Respect the Current Process, Roles & Responsibilities;
• Principle 4: Encourage Acts of Leadership at All Levels.
 KANBAN PROCESS – 6 Practices

• Visualize the Workflow;
• Limit Work in Progress;
• Manage Flow;
• Make Process Policies Explicit;
• Implement Feedback Loops;
• Improve Collaboratively (using models & the scientific method).
 AGILE METHODOLOGY: KANBAN PROCESS
• Kanban as a workflow management method designed to help us visualize 
our work, maximize efficiency and be agile. 

• The best way to visualize our work is by creating and using a Kanban board. 

• The simplest one may consist of three columns – “Requested”, “In 
Progress,” and “Done”.
AGILE METHODOLOGY: KANBAN PROCESS
AGILE METHODOLOGY: KANBAN PROCESS METRIX 
(Trello.com free) 
AGILE METHODOLOGY: KANBAN SWIMLANE PROCESS
AGILE METHODOLOGY: KANBAN (JIRA used)
 Disadvantage of Scrum
• Scrum works according to the emphatic guide. ‘Sprints must be time‐
boxed to a month or less’. This rule is decelerating the working pace of 
the teams due to unpredictability.
• Scrum teams are asked to deliver the increments in software‐ designed, 
coded and tested to the stakeholders, in a very short span i.e. end of 
each sprint. This causes more ‘anxiety’ among the team members.
• Scrum teams have to entirely commit to the customers’ requirements. In 
case they fail to achieve the high‐priority target, they might have to 
decide to add some technical debts to solve the time‐boxed problem.
 Disadvantage of Kanban
• Kanban provides a very linear technique of work. So, it is believed that 
the Kanban can only be used in the systems which have repeatable 
processes.
• Kanban is not very useful in complex systems (where requirements may 
change) like software development process as the software needs 
change at each and every point.
 Overview of Scrumban

• Visualizes work flow with the Kanban board
• Utilizes daily scrum
• Work is pulled rather than assigned
• Strict work in process limit in (Doing column)
• Project teams roles not clearly specified
• Specialized team members
 Types of Scrumban depends on 

• Continuous flow Scrumban
Fluid movement of Work‐ no timeboxes
Pull items into Doing based on team capacity
Plan at a certain number of To Do items
Lead and cycle times are key metrics

• Timebox Scrumban
Utilizes sprints (1‐4 weeks)
Iteration planning, reviews and 
retrospectives
Uses Ready status to organize item
Uses lead and cycle time
Kanban + Scrum = Continuous flow Scrumban
Kanban + Scrum = Timebox flow Scrumban
What methodology to Use and When?
 What methodology to Use and When?
• Assess the project size and scope:
• Large & lengthy project may have difficulty to break down into two-week sprints.

• If the scope is difficult to define & expected to evolve over time, Agile is likely a better fit.

• Determine project drivers: Before initiating a project, it’s important to understand its business case and value to the organization.

• Understand the customer’s key goals, expected outcomes, and priorities for the project.

• Identify how different methodologies affect above points

• Whichever methodologies supports the majority of the drivers, goals, outcomes, and priorities should be
your chosen one. You should choose the one with best results with the lowest amount of risk.

• Once you’ve chosen your framework, monitor how it’s working. Remember a key concept of Agile is
flexibility and adaptability. If the project methodology you’ve chosen isn’t producing your desired results,
you may need to modify it or even change methodology.
In today’s Agile world, 75% of Agile teams are doing some flavor of Scrum.
https://agilemanifesto.org/principles.html
 The Principles of the Disciplined Agile Mindset (https://www.pmi.org/disciplined‐agile/principles)
1. Delight Customers: We need to go beyond satisfying our customers' needs, beyond meeting their expectations, and strive to
delight them. If we don't then someone else will delight them and steal our customers away from us. This applies to both
external customers as well as internal customers.
2. Be Awesome: We should always strive to be the best that we can, and to always get better. Who wouldn't want to work with
awesome people, on an awesome team for an awesome organization?
3. Context Counts: Every person, every team, every organization is unique. We face unique situations that evolve over time. The
implication is that we must choose our way of working (WoW) to reflect the context that we face, and then evolve our WoW as
the situation evolves.
4. Be Pragmatic: Our aim isn't to be agile, it's to be as effective as we can be and to improve from there. To do this we need to be
pragmatic and adopt agile, lean, or even traditional strategies when they make the most sense for our context.
5. Choice is Good: To choose our WoW in a context-driven, pragmatic manner we need to select the best-fit technique given our
situation. Having choices, and knowing the trade-offs associated with those choices, is critical to choosing our WoW that is best
fit for our context.
6. Optimize Flow: We want to optimize flow across the value stream that we are part of, and better yet across our organization,
and not just locally optimize our WoW within our team. Sometimes this will be a bit inconvenient for us, but overall we will be
able to more effectively respond to our customers.
7. Organize Around Products/Services: To delight our customers we need to organize ourselves around producing the offerings,
the products and services, that they need. We are in effect organizing around value streams because value streams produce
value for customers, both external and internal, in the form of products and services.  We chose to say organize around
products/services, rather than offerings or value streams, as we felt this was more explicit.
8. Enterprise Awareness: Disciplined agilists look beyond the needs of their team to take the long-term needs of their organization
into account.  They adopt, and sometimes tailor, organizational guidance.  They follow, and provide feedback too,
organizational roadmaps.  The leverage, and sometimes enhance, existing organizational assets.  In short, they do what's best
for the organization and not just what's convenient for them.
For additional reading refer:
https://disciplinedagileconsortium.org/DA‐Whitepapers‐Articles