Agile Project Management Tips and Techniques in a simple way

1. Agile Project Management – Tips
and Technique
Bhawani Nandan Prasad
B.E. IT and MBA Strategy &
Marketing
1

2. Agile for Scrum
Masters, PORs,
and PMs
2

3. Waterfall vs. Agile Success
Rates
3

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. The Agile Process
• Calling ourselves Agile is no guarantee of
success.
• Agile, just like Waterfall, must be done well
to be successful.
11

12. Requirements Envisioning
12
The
Stakeholder
shares their
vision with the
POR and (if a
large idea)
with a Project
Manager.
Product Owner
Representative

13. 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

14. Add Tickets and Bug Fixes
14
The POR
evaluates
tickets and
bugs, then
creates user
stories for
them.
Product Owner
Representative

15. 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

16. 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

17. 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

18. 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

19. 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. 20
PMs Review Tracking and Estimate Project
Completion. (This is NOT a commitment)

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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

30. 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

31. 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

32. 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

33. 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

34. 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

35. Our Goal: Deliver Value Faster
35

36. 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

37. 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

38. 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.

39. Backlog Tracking
39
This was expected
as epics were
defined better.

40. 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.

41. Backlog Tracking
41
True Panic
Set In As
Dark Matter
Appeared

42. 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.

43. 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

44. 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

45. 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

46. 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

47. 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. 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. 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. 50
features
release
engine
transmission
suspension
brakes
exteriorbody
Interiorseating
tires
sprint1234
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. 51
usertaskstosupport
releaseD D D D D I IB- C C- D D D DA- B B- B B B B-A- A B A A- A- B-
sprint
1234
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
engine
transmission
suspension
brakes
exteriorbody
Interiorseating
tires

52. 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. 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

54. 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

55. 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

56. 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.

57. 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

58. 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

59. Questions
59

60. Class
Retrospective
60