Agile Project Management
1
2
World Before Agile Methodologies
Sequential Development
3
Sequential Development
4
Fixed Requirements
Estimated Effort Estimated Time
(Resources)
Agile Software Development
5
Fixed Effort
Fixed Time
(Resources)
Estimated Requirements
Cone of Uncertainty
6
Agile 4 Values
Individuals & Interactions
Over
Processes & Tools
Working Software
Over
Comprehensive Documentation
Customer Collaboration
Over
Contract Negotiation
Responding to Change
Over
Following a Plan
Individuals &
Interactions Processes &
Tools
Working
Software Comprehensive
Documentation
Customer
Collaboration Contract
The Agile Manifesto argues that although Negotiation
the concepts on the right have value, those
on the left have greater value. Responding
to Change Following a
Plan
Agile 12 Principles
Our highest priority is to satisfy the customer through early
and continuous delivery of valuable software.
Deliver working software frequently, at intervals of
between a few weeks to a few months, with a preference
to the shorter timescale.
Working Software is the primary measure of progress
Welcome changing requirements, even late in development.
Agile processes harness change for the customer's competitive
advantage
Continuous attention to technical excellence and good
design enhances agility
Agile processes promote sustainable development. The
sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
Simplicity
the art of maximizing the amount
of work not done—is essential.
Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get
the job done
The best architectures, requirements, and designs emerge
from self-organizing teams
Business people and
developers must work
together daily
throughout the project
The most efficient and effective method of conveying
information to and within a development team is face-to-
face conversation
At regular intervals, the team reflects on how to become
more effective, then tunes and adjusts its behavior
accordingly
Scrum
Scrum Roles:
1-Product Owner
2-Scrum Master
3-Development Team
Sprint:
Scrum divides a
project into iterations
(called sprints) of
fixed length (usually
two to four weeks).
Product Increment:
Each sprint results in a potentially releasable/shippable product (called an increment).
Product Backlog:
The product owner manages a prioritized list of planned product items. The product backlog
evolves from sprint to sprint (backlog refinement).
Sprint Backlog:
At the start of each sprint, the Scrum team selects a set of highest priority items from the product
backlog. Since the Scrum team, not the product owner, selects the items to be realized within the
sprint, the selection is referred to as being on the pull principle rather than the push principle.
Definition of Done:
To make sure that there is a potentially releasable product at each sprint’s end, the Scrum team
discusses and defines appropriate criteria for sprint completion. The discussion deepens the team’s
understanding of the backlog items and the product requirements.
Timeboxing:
Only those tasks that the team expects to finish within the sprint are part of the sprint backlog. If
the development team cannot finish a task , it is moved back into the product backlog.
Transparency:
The development team reports and updates sprint status on a daily basis at a meeting called
the daily scrum. This makes the progress of the current sprint visible to everyone.
Whole-Team
Approach
• Involve everyone necessary to ensure
success
• Small team (from 3 to 9)
• Team is Co-located
• Quality is everyone’s responsibility
• Power of Three:
The concept of involving testers, developers, and
business representatives in all feature discussions
Early &
Frequent
Feedback
• In sequential models, early & frequent feedback is not applied
• the customer does not see the product early
• It’s too late to change
• The result is unhappy customer and badly managed team
Use early & frequent feedback to:
• Focus on the features with the highest business value and deliver them
first
• Manage the team better through transparency
• Discover quality problems early
Retrospectives
Retrospective is a meeting held at the end of each iteration to discuss what was successful, what
could be improved, and how to incorporate the improvements in future iterations.
All team members can provide input on all activities
Burn-down Chart
Agile Requirements
Themes 46
Ø A scrum theme is the highest level of the story hierarchy. It describes a view of a tangible
product or an abstract goal (such as performance tuning). A product owner further breaks
down a theme into one or more epics. You may group features into themes in your product
roadmap.
Features
47
Ø A feature is a new capability provided to customers. Features are part of products at a very
high level.
Epic User Story
48
Ø Medium-sized requirements that are decomposed from a feature
User Stories
49
Ø Requirement that contain s a single action
User Tasks
50
Ø Actions required to develop a requirement of a user story
The User Story
Who are your users?
52
53
Example Product User Roles:
Ø Visitor
Ø User with basic subscription
Ø Premium user
Ø User Role != Stakeholder
User Stories
are written to capture requirements from the perspectives of developers, testers, and business
representatives. The user stories must address both functional and non-functional characteristics.
User Stories
Focus on What & Why not How?
3C Concept
A user story is a conjunction of three elements:
1-Card: The physical media describing a user story
2-Conversation: Explains how the software will be used
3-Confirmation: The acceptance criteria are used to confirm the user story
INVEST Technique
INVEST Technique
helps to assess the quality of a user story, the user story should be:
1-Independent: of all other user stories
2-Negotiable: A story is an invitation to a conversation (Focus on Why not how)
3-Valuable: If a story doesn’t have a value, it should not be done
4-Estimatable: Stories should provide enough information so they can be estimated
5-Small: So as to fit within an iteration
6-Testable: Even if the team doesn’t have testers
Planning in Agile Projects
63
1-Product vision
Ø Describe the goals of the product
Ø Creator: product owner
Ø Should be done at least one time per year
64
2-Product roadmap
Ø High-level view of product requirements that create the product
vision
Ø Creator: Product owner
Ø Should be done at least two times per year
65
3-Release planning
Ø Plan which product increments (versions) get released to the
market and when
Ø Creator: Product owner
Ø Should be done at least quarterly
66
4-Sprint planning
• Create iteration goals, tasks and deliverables
• Creator: Product owner + Development team
• Each one to four weeks
5-Daily Scrum 67
Ø Discuss today’s tasks that will help in reaching the iteration’s goal
Ø Creator: Development team
Ø Should occur daily
6-Sprint review 68
Ø Demonstration of working product
Ø Creator: Product owner + Development team
Ø Should occur at the end of each sprint
7-Sprint retrospective 69
Ø Discuss processes and environment and make plans for process
improvements in the next sprint
Ø Creator: Whole team
Ø Should occur at the end of each sprint
How to use Jira
(Scrum Project)
Course Content
• What is Jira
• Managing Sprints
• Creating Epics
• Creating User Stories
• Creating tasks & bugs
• Creating & Reading reports
• Kanban Board
71
What is Jira?
72
Creating a Scrum Project
73
Creating Epics
74
Creating
User
Stories
75
Creating
Acceptance
Criteria
76
Assigning Story points
(planning Poker)
77
Creating Sprints
78
Daily Stand-up Meeting
Velocity
Chart
•The velocity chart displays the average
amount of work a scrum team
completes during a sprint.
• Teams can use velocity to predict how
quickly they can work through the
backlog because the report tracks the
forecasted and completed work over
several sprints.
•The more sprints, the more accurate
the forecast.
80
Burndown
Chart
• A burndown chart shows the amount
of work that has been completed in
an epic or sprint, and the total work
remaining.
• Burndown charts are used to predict
your team's likelihood of completing
their work in the time available.
• They're also great for keeping the
team aware of any scope creep that
occurs.
81
Retrospectives
•A retrospective is a meeting held
after a product ships to discuss what
happened during the product
development and release process,
with the goal of improving things in
the future based on those learnings
and conversations.
82
Lean Software Development
Eliminating Waste & Managing Flow
Lean Software Development 84
• Lean Software Development is a translation of lean manufacturing principles and practices to the software
development domain.
• Lean Software Development is a set of principles that can be applied to software development to decrease
programming effort, budgeting, and defect rates by one third.
85
Lean is a mindset
(not a methodology)
86
1-Eliminate Waste
1. Partially done work
2. Extra processes
3. Extra features
4. Task switching
5. Waiting
6. Motion
7. Defects
87
2-Amplify Learning
• Learn from what you do and use feedback to keep improving
88
3-Decide as late as possible
• Make every important decision for your project when you have the most information about it
• Don’t force yourself to decide things that don’t need to be decided yet
89
4-Deliver as fast as possible
• Keep track of how you work, where you’re running into delays, and how those delays impact your
team
90
6-Build integrity in
• The client and development team work together in planning the product
• This entails a larger planning session at project initiation and smaller sessions at each iteration
91
7-See the whole
• When everyone on the team can see what everyone else is doing, the team can collaborate on the
best way to get the work done
Kanban
Kanban is a management approach that is sometimes used in Agile projects. The general
objective is to visualize and optimize the flow of work within a value-added chain.
Kanban Board:
Each column shows a station, which is a set of related activities. The items are symbolized by tickets moving
from left to right across the board through the stations.
Work-In-Progress Limit:
Each column shows a station, which is a set of related activities. The items are symbolized by tickets moving
from left to right across the board through the stations.
Lead Time:
Kanban is used to optimize the continuous flow of tasks by minimizing the (average) lead time for the complete
value stream
How to use Trello
as a Kanban tool
Extreme Programming
99
• Extreme programming :
Extreme programming (XP) is an agile methodology that’s been popular with software
teams since the 1990s. XP is focused on project management (like Scrum), but also on how
teams build code.
100
• Quarterly Cycle: Once a quarter, the XP team organizes meetings to do
planning & reflection
• Weekly Cycle: The weekly cycle practice is a one-week iteration in which
the team chooses stories and builds working software that’s “Done” at the
end of the week.
• Slack: Any time the team creates a plan, the team adds a slack by including
a small number of optional or minor items.
101
Extreme programming :
ü New builds may be built several time per day
ü Increments are delivered to customers every 1 to 2 weeks
ü All tests must be run for every build and the build is only accepted if tests run
successfully
102
Why Extreme?
XP embraces five values to guide development:
communication, simplicity, feedback, courage, and respect.
105
1-The Planning Game
ü The client and development team work together in planning the product
ü This entails a larger planning session at project initiation and smaller sessions at each
iteration.
106
2-Small Releases:
ü Releases must occur as frequent as possible to gain plenty of feedback, which is best
achieved if releases are small in terms of required new functionality.
ü Smaller releases also allow estimates to be more certain; it is easier to look a week or
two ahead, rather than months. So, in the extreme, keep the iterations very short.
107
3-System Metaphor
ü A system metaphor makes it easier to explain the product to someone else; it can be an
analogy to describe the product to someone who is not technical.
ü Examples: Desktop & Shopping Cart
108
4-Simple Design
ü Focus on the simplest design that works to satisfy the client’s needs.
ü Requirements change, so it would be wasteful in making elaborate designs for
something that will change.
ü Do not over-engineer the design for a future that may not come. So, in the extreme,
make the simplest thing that works.
109
5-Continuous Testing
ü In XP, tests are prepared for a required feature or functionality before its corresponding
source code is written.
ü We use Test-Driven Development
110
6-Refactoring
ü Restructure the internal design of the code without changing its behavior.
ü A large, module can be decomposed into smaller more understandable pieces.
ü Unnecessary code can be removed
ü If refactoring is neglected, technical debt is increased.
111
7-Pair Programming
ü Two developers work side-by-side at one computer to work on a single task
112
8-Collective Code Ownership
ü No individual owns the code
ü The produced work is the result of the team, not individuals. So, project success and
and failure resides with the team, not on specific developers.
113
9-Continuous Integration
ü Developers combine their code often to catch integration issues early. This should be at
least once daily, but it can be much more frequent.
114
10-40-hour work week
ü XP respects the developer’s balance of work and life.
ü At crush time, up to one week of overtime is allowed, but multiple weeks of overtime
would be a sign of poor management or estimation
115
11-On-site customer
ü The client is situated near the development team throughout the project to clarify and
answer questions
116
12-Coding standards
ü All the developers agree to and follow a coding standard that specifies conventions on
code style, formatting, and usage
ü This makes the cod easier to read, and it encourages the practice of collective ownership
• XP provides guidance on how testing &
development should be done.
• Agile teams following Scrum often
incorporate XP practices
• Scrum doesn’t dictate specific software
development techniques
• Scrum doesn’t provide guidance on how testing has
to be done
• Visualizing tasks is important in Scrum
• Iterations & Timeboxing are important in Scrum
• In Kanban, visualizing tasks is important to provide
transparency
• Iterations in Kanban are optional
• Timeboxing in Kanban is optional
Difference between
Agile & Traditional Testing
• Hardening or Stabilization Iterations may occur periodically to resolve any
lingering defects and other forms of technical debt
• However, the best practice is that no feature is considered done until it has
been integrated and tested with the system
• Fix Bugs First is to address defects remaining from the previous iteration at
the beginning of the next iteration
• However, some complain that this practice results in a situation where the
total work to be done in the iteration is unknown
Test Pyramid
Test-Driven Development
What if we want to apply TDD on a function to calculate a circle area?
What if we want to apply TDD on a function to calculate a circle area?
What if we want to apply TDD on a function to calculate a circle area?
What if we want to apply TDD on a function to calculate a circle area?
Behavior-Driven Development
Continuous Integration
Continuous Integration merges all changes made to the software and integrates all changed
components regularly, at least once a day.
Tips for Agile Remote Teams
Agile Adoption Rate Survey Results
Team Location Success Percentage
Collocated Scrum Team 83%
Dislocated but physically 72%
reachable
Distributed across 60%
geographies
Use videoconferencing
Arrange
in-person
meetings
Use an Online Collaboration Tool
Include Scrum team members’
pictures on online
collaboration tools
Understand Time
zone differences
Be flexible because of
time zone differences
In case of Ambiguity,
ask for clarification by phone or video
Be aware of language
and cultural differences
Discuss non-work topics
