Agile Project Management – Tips
and Technique
Bhawani Nandan Prasad
B.E. IT and MBA Strategy &
Marketing
1
Agile for Scrum
Masters, PORs,
and PMs
2
Waterfall vs. Agile Success
Rates
3
Business Process Stakeholder • The Process Stakeholder “owns” a portion of
The Company’s business process and uses
software (the product) as a tool to execute the
process.
• Defines changes to the business process and
the corresponding changes to the software
product and prioritizes them by business value
• This leads to requests to IT for release date
and product content
• Works with Product Owner Reps and
Project Managers to define work.
• Accept or reject work results
Stakeholder
End User • The End User is the person who actually uses
the software product or business process we
develop
• Provide feedback on the utility and usability of
the product
• Often desires improved usability
and new features.
• Works with POR to define and test
End User
Product Owner
Representative
Product Owner Representative • Works with the Stakeholders to elicit the
product requirements, enters them into the
product backlog, and then communicates and
translates the stakeholder’s vision of the
product to the scrum team
• The Product Owner Rep is the person who
conveys the Stakeholder to the team
when the Stakeholder is not present.
• Helps prioritize features according to
business value and performs
backlog grooming
• Accept or reject work results
Project Manager • The Project Manager “Owns” a software
project chartered to develop a significant
enhancement to an existing software product
or develop a new software product.
• Works with the Stakeholders and POR to elicit
the product requirements, ensures that they
are entered into the product backlog.
• Helps prioritize features according to
business value and performs
backlog grooming
• Tracks and reports progress
• Coordinates with multiple scrum teams/PORs
Project Manager
IT Management Group • The IT Management Group “Owns” the
existing software products and the software
development resources.
• Works with the Stakeholders to prioritize new
features development, fixes, and
enhancements according to business value.
• Resolves priority conflicts among stakeholders
• Coordinates across multiple projects,
scrum teams, and PORs.
• Controls development pace and
order by prioritization
IT Management
Scrum Master
• Represents management to the project
• Responsible for enacting agile values and practices
• Removes impediments
• Ensure that the team is fully functional and productive
• Enable close cooperation across all roles and functions
• Shield the team from external interferences
• Work closely with the Product Owner Rep
Scrum Master
Scrum Team • Typically 5-9 people
• Cross-functional:
– BA, Programmers, testers, user experience designers, etc.
• Members should be full-time
– May be exceptions (e.g., database administrator)
• Membership should change only between iterations
Scrum Team
The Agile Process • Calling ourselves Agile is no guarantee of
success.
• Agile, just like Waterfall, must be done well
to be successful.
11
Requirements Envisioning
12
The
Stakeholder
shares their
vision with the
POR and (if a
large idea)
with a Project
Manager.
Product Owner
Representative
Requirements Capture
13
The POR and (if
working on a large
idea) Project
Manager capture
the requirements as
user stories (often
of epic size) and
enter them into the
product backlog.
Product Owner
Representative
Add Tickets and Bug Fixes
14
The POR
evaluates
tickets and
bugs, then
creates user
stories for
them.
Product Owner
Representative
Continuous Backlog Grooming
15
The POR and (if
working on a large
idea) Project
Manager review the
requirements (user
stories) to
determine if they
completely describe
the function. If not,
add more.
Product Owner
Representative
Continuous Backlog Grooming
will become very important
16
The POR and team
decompose the
user stories into
ready stories with
complete
acceptance criteria.
If stories have
dependencies note
this in the backlog.
Stories must be
sized. Scrum Team
Product Owner
Representative
Grooming Exercise
• What should the SM do if a high priority
story (epic sized) is assigned to a team for
the next sprint?
• What should the POR do if this story has
no acceptance criteria?
• What should the SM do if this story has a
dependency on team 3 completing story 6
before your story can be tested?
17
Backlog Prioritization
18
Management
prioritizes and
tentatively
assigns all the
user stories to
teams with input
from all
Stakeholders,
PORs, PMs, and
Scrum Masters.
High Priority
Low Priority
Project Tracking
19
PM tracks all
the user stories
for the project
release(s). If
project timeline
does not meet
user needs,
then PM must
escalate to
Management
High Priority
Low Priority
20
PMs Review Tracking and Estimate Project
Completion. (This is NOT a commitment)
Project Exercise
• Precisely when will Project A be released?
• When will Project C be released?
• What will happen if a high priority fix takes
all of team C’s time in Sprints 2 and 3 in
release 1?
• What should the Scrum Master do?
• What should the PM do?
• What can the POR do?
21
Team Tracking
22
SM tracks all
the user stories
assigned to the
team for future
iterations. If
team velocity
cannot support
the load, then
SM must
escalate to
Management
High Priority
Low Priority
Scrum Master
Backlog Grooming
23
As the user stories
approach the top
of the product
backlog, the POR
will review ready
stories with
Stakeholders to
ensure stories are
still ready and
clear.
High Priority
Low Priority
Product Owner
Representative
Sprint Planning
24
At the start of a
sprint, the scrum
master and team
commit to develop
the top user stories
assigned to them
based on the team
velocity and
availability. The
POR helps clarify
the user story.
High Priority
Low Priority Scrum Team
Scrum Master
Sprint Planning
25
If the user story is
not clear, or has
dependencies that
are not yet met, or
is too big to do in
one sprint, then do
not commit. Do
not assume DB or
outside groups will
deliver on your
schedule.
High Priority
Low Priority Scrum Team
Scrum Master
Sprint Planning Exercise
• Why is the “one team” concept helpful in
planning?
• What should the SM do if it looks like the
sum of the tasks are 10 hours longer than
time available?
• If another team has 10 hours of available
time, could the work be sent to them?
• What should you do if the story suddenly
looks much bigger than initially sized? 26
Sprint Execution
27
The scrum team
designs, codes, and
unit tests the user
stories. QA tests
the code (based on
acceptance criteria)
and must certify
that it is “done”.
The code is now
ready for Integration
Testing.
Scrum Team
User
story
User
story
User
story
Sprint Execution
28
SM uses sprint burn
down chart to find
stories that are not
likely to be “done”
on time. These
should be split,
dropped, or must be
sent into the next
sprint. Scrum Team
User
story
User
story
User
story Scrum Master
SM Exercise
• If a story is not ready on the last day of the
sprint, what can I do?
• Can I break stories into two new stories:
– A. Code , B Test
– A. Spike , B Initial Story
– A. ½ Story , B Other ½ story
• What will this do to my team velocity?
29
Sprint Demo (end of sprint)
30
The scrum team demos the
coded features to the POR and
Stakeholder. They accept or
reject the features. Rejected
move to next sprint.
Scrum Team
User
story
User
story
User
story
Release to Production
31
Every 6 weeks (3 sprints) the
accepted features are put into
Minimal Functional Releases
and deployed to production.
User
story
User
story
User
story
User
story
User
story
User
story
MFR
Release to Production
32
PMs, PORs, and Scrum Masters
must define MFR content with
help from Stakeholders and
Management. Features not
released must be held for next
MFR.
User
story
User
story
User
story
User
story
User
story
User
story
MFR
MFR Exercise I need to charge taxes on a service stories
(each is 1 sprint of effort):
1. Tax calculation logic
2. Display tax
3. Enter tax exempt number
4. Validate tax exempt number
5. Manual code to override tax (MI is exempt)
6. Remove tax from subtotal
7. Automate tax override with codes
•What order if I am starting 2nd sprint in the
release? What are potential MFRs?
33
MFR Exercise • What happens if these stories are part of a
ILMS phase 7 project?
• Who decides in what order the stories
should be developed?
• What if story 4 (Validate tax exempt
number) has a dependency on web
services creating the access to the fed
database?
• What will you do if a high priority fix
causes you to delay story 6 (remove tax)
by 1 sprint? 34
Our Goal: Deliver Value Faster
35
Agile is Adaptive
• Agile planning is adaptive.
• It also means that because our
requirements are vague, so are any
estimates.
• PMs use story point size estimates and
team velocity to forecast ranged delivery.
• Adaptive teams can plan which features
they intend to do next month, but this is
not a commitment.
36
Commitments • Confusing Estimates with Commitments
is commonplace, and leads to failed projects
• Estimates are the responsibility of the people doing the work
• Targets are set by the people paying for the work
• Commitments are agreements between the people doing the work, and the people paying for the work
• Commitment is achieved through negotiation
Backlog Growth • Agile Backlogs tend to grow, especially at the
start of a project.
• This is normal since jumping into
development with minimal requirements
envisioning means that some features are
missing, many are poorly defined, and most
are underestimated. (just like waterfall)
• All of these lead to expected growth, which
should be encouraged through emphasis on
good, initial backlog grooming sessions.
Backlog Tracking
39
This was expected
as epics were
defined better.
Dark Matter • Both waterfall and agile projects have the
same amount of dark matter (missed or
unknown requirements).
• Agile finds dark matter faster since the
iteration reviews force users to visualize
and then realize what is missing.
• Agile is adaptive, so it allows the backlog
(requirements) to incorporate these
missed requirements while the project is
being developed.
Backlog Tracking
41
True Panic
Set In As
Dark Matter
Appeared
Stakeholder Priority Changes • Sometimes Stakeholders are forced to
change priorities, making the current
project less important or adding high
priority fixes or enhancements to the mix.
• This is another reason why agile does not
try to be predictive.
• Agile POs and PMs update their estimates
at this point so that they can have a
discussion with stakeholders about the
impact of these changes.
How Should I Work With Agile?
1. Ensure user involvement
2. Use adaptive planning.
3. Prioritize release content to maximize
business value.
4. Use adaptive measurement
5. Work to overcome drawbacks of large
and distributed projects
6. Be transparent. All our reports and
findings are published to Share Point.
43
Stakeholder Involvement • Active support, and engagement of
business users is the most critical factor.
• Without significant, constant product
owner participation, the agile teams have
no way to derive requirements and no
feedback to tell whether the system is
meeting those requirements.
• Agile is evolutionary only when users
provide feedback and recognize the “dark
matter” requirements early in
development. 44
What Must You Do?
• Work with Stakeholders as needed (daily)
to define their vision and clarify stories.
• If there is lack of stakeholder participation,
you must escalate to management.
• This could result in planned delays.
• Work with Management to groom backlog
(establish priorities, break down stories)
• Review the product and release plans on
a regular basis to determine if they will
deliver functionality within targeted dates. 45
Adaptive vs. Predictive Planning • Negotiate Scope and
decompose features to achieve
scheduled targets
• Use ranged estimates which
reflect the amount of uncertainty
in the information which our
estimates are based on.
• Focus on delivering maximum
value within each release
• Revisit and refine plans every
iteration and release
46
Plan Releases to Production
• Frequent releases to production provides
maximum value to the business.
• Ask how can I plan to gain maximum value
in each release?
47
48
Build out releases based on VALUE (three
general classifications for product features: must-have, one-dimensional, and delighter )
“This car has many flaws. Buy it
anyway. It’s so much fun to drive”
-- from a NY Times review of the
Mini Cooper
Must-haves The products must
have this features for
me to be consider the
product acceptable One-dimensionals The more of this I get,
the better Delighters I love this element of
the product!
49
Use these classifications to both
prioritize and split
Brakes
(must have)
Basic brakes
(must have)
Stopping
distance (one dimensional)
Anti-locking
(delighter)
Cool dashboard light when slipping
(delighter)
Keep in mind: you must know your customers and users to determine subjective value.
One person’s delighter may leave others apathetic.
Another’s must have is useless to other customers
50
featu
res
release
en
gin
e
tra
nsm
issio
n
su
sp
en
sio
n
bra
ke
s
ex
te
rio
r b
od
y
In
te
rio
r se
atin
g
tire
s
sprint 1 2 3 4
Product goal: (in 4 sprints) be driving the coolest car in town
Let’s look at what happens if we take
an incremental only approach to
construction of our dream car. We want to release
in 4 sprints.
51
user
tasks to s
upport
release D D D D D I I B- C C- D D D D A- B B- B B B B- A- A B A A- A- B-
sprint
1 2 3 4
Product goal: (in 4 sprints) be driving the highest quality car possible
Instead, building up quality iteratively
ships the best product
• Early iterations build bare necessities, later
iterations build up quality
• Evaluating readiness based on subjective quality
to understand doneness
en
gin
e
tra
nsm
issio
n
su
sp
en
sio
n
bra
ke
s
ex
te
rio
r b
od
y
In
te
rio
r se
atin
g
tire
s
52
Release Strategy
Opening Game: Build all necessary features
first Mid-Game: Add flexibility and safety next
End Game: Finish with comfort, performance,
and luxury
Reserve time in the remaining third for
unforeseen additions and adaptations
53
Look at the release of business
value over time
To finish on
time we may
“trim the tail”
by deferring
stories of
modest value
Guidelines for releasing on time
• PMs and PORs must thin and decompose
aggressively during early sprints to build all
essential functionality on time.
• Build up capability, flexibility, and safety
only after all necessities are in place.
• Protect time in the final sprints for product
refinement (adding more safety and then
usability, performance, and sex appeal).
• Assess release readiness at the end of
each sprint as part of product review.
54
Large and Distributed Projects
• As project size (and hence timescale)
increase, the failure rate increases for
Agile Projects (but less than for waterfall).
• If Stakeholders and PORs do not have a
clear vision, the project can drift until
money runs out.
• Distributed teams are still a challenge.
• Since face to face communication is a key
practice, scrum masters and their teams
must work hard to bridge this gap.
55
Establish and Follow Common
Agile Processes
56
• We are developing common agile
development and release processes.
• We will meet in Scrum of Scrum meetings
to escalate blockages that cannot be
handled within a team to the management
level.
• We will work in Scrum Master meetings to
help each other with our agile practices.
• We will communicate extensively to
ensure group awareness.
Establish More Development
and Test Environments
57
• Software needs to be tested in an environment
that resembles the production environment
• This is a large challenge for many organizations
adopting an iterative approach
– They do not have enough testing
environments to provide appropriate isolation
– They have difficulty configuring appropriate
environments as quickly as they are needed
– They are not used to having teams deploy
software into testing environments with high
frequency
You Will Experience Failure
• Failure is not a single, cataclysmic event. You don't fail overnight. Instead, failure is a few errors in judgment, repeated every day. Jim Rohn
• My great concern is not whether you have failed, but whether you are content with your failure. Abraham Lincoln
• A failure is not always a mistake, it may simply be the best one can do under the circumstances. The real mistake is to stop trying. B. F. Skinner
58
Questions
59
Class
Retrospective
60
Top Related