Organizations, teams and even project management software are increasingly responding to a demand for more adaptive and evolutionary processes. In a fast-changing business world that needs to respond to rapid market and technology shifts, Agile delivers. Agile project management provides numerous benefits to organizations, project teams, and products. Learn more about: » Set up an Agile project. » Assign roles and responsibilities. » Create a prioritized list of requirements. » Define increments and timeboxes. » Manage a Solution Development Team or Teams. » Use Agile techniques such as Feature Driven Development. » Present the benefits of Agile approaches to Senior Management.

1. Agile Project Management
We manage learning.
“Building an Innovative Learning Organization. A Framework to Build a Smarter
Workforce, Adapt to Change, and Drive Growth”. Download now!

2. NetCom Learning

3. NetCom Learning – Managed Learning Services

5. Agenda
Module 1: Project Management – A Reality Check
Module 2: Overview of Waterfall Model
Module 3: Understanding Agile Development
Module 4: Understanding Agile Project Delivery
Module 5: Deep Dive – SCRUM Framework
Module 6: Deep Dive – Lean Methodology
Module 7: Applying SCRUM & Lean to Non-IT projects
Module 8: Requirements Management
Module 9: Estimation
Module 10: Project Planning
Module 11: Project Execution and Tracking
Module 12: Agile Adoption
5

6. Module 1
Project Management – A Reality Check
6

7. Are We Building the Right Thing?
7

8. Challenges of a Project Manager
1. Dealing with changing requirements (Scope Creep)
2. Lack of resources and/or Quality of resources
3. Unrealistic schedules
4. Issues with technologies – unproven, nascent
5. Overburdened by existing complexity – documentation, reporting,
etc.
6. Too many dependencies
7. Managing stakeholder expectations
8

9. Module 2
Overview of Waterfall Model
9

10. Waterfall Model
10
1. Simple and easy to understand and use.
2. Easy to manage due to the rigidity of the model.
3. Phases are executed and completed one at a time. No overlaps.
4. Works well for non-complex projects.

11. Understanding the Waterfall Model
11
1. Freeze the end-product in all respects when project starts
2. Requires detailed estimation and planning upfront
3. Changes mid-way can cause delays

12. Challenges with the Waterfall Model
1. Managing changing requirements during the ALM/SDLC
2. Don’t get to see the end product until the end of ALM/SDLC
3. Loaded with risk and uncertainty
4. Challenges in dealing with complexity upfront
12

13. Module 3
Understanding Agile Development
13

14. Understanding Agile Development
• Agile Development is an alternative to traditional project
management
• Focus on customer satisfaction
• Adapts well to deal with uncertainties and changing situations
• Delivers in increments following an iterative process
• Continuous attention to all aspects of delivery – Planning, Design,
Delivery, Quality...
• Empowers team to make decisions
• Follows an inspect-and-adapt approach
14

15. Traditional vs. Agile - Lifecycle
Agile = Deliver Value Early
15

16. Traditional vs. Agile – Value Proposition
16

17. Traditional vs. Agile – Value Proposition
17

18. Traditional vs. Agile – Value Proposition
18

19. Projects Suited for Agile Delivery
19
The most appropriate projects for agile are ones with aggressive
deadlines, high degree of complexity, and high degree of novelty
(uniqueness) to them.
Novelty: If you are building the same things
over and over again, you have mastered the
nuances. You don’t need Agile
Urgency : Time boxes and iterations keeps the
intensity and focus going
Complexity: Anything that requires that extra
bit of functionality or variation that is unique.

20. Module 4
Understanding Agile Project Delivery
20

21. Are We Building the Right Thing?
21

22. The Promise That Agile Holds
22

23. The Paradigm Shift
23
• Plan Driven Approach: Scope remains fixed, while Resources and Schedules are
adjusted
• Change Driven Approach: Scope is adjusted while Resources and Schedules are
fixed

24. Agile Framework
24
Relationship between Values, Principles and Practices

25. Agile Manifesto (Values)
25

26. 12 Principles of Agile Development
26
1. Satisfying customer is top priority
2. Welcome changing requirements even late in development
3. Deliver working software frequently
4. Development teams and business work together
5. Most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
6. The primary measure of success is working software
7. The Team regularly reflects on work
8. Build projects around motivated people
9. Continuous attention to technical excellence and good design
10. Simplicity – the art of maximizing the amount of work not done—is essential
11. The best architectures, requirements and designs emerge from self-organizing
teams
12. Agile processes promote sustainable development – Sponsors, developers and
users should be able to maintain a constant pace indefinitely

27. Agile Process Framework
27

28. Agile Methodology Flavors
28

29. Xtreme Programming
29

30. XP Values
30
Communication: Building and disseminating institutional knowledge among members
of the development team. Helps developers have a shared vision. Happens through
collaboration between users and developers, frequent verbal communication, and
feedback, simple design, common metaphors.
Simplicity: Start with a simple solution. Extra functionality can be added later.
Feedback: Feedback looked in three dimensions : Feedback from the system,
Feedback from the customer and feedback from the developers.
Courage: Developers feel comfortable with refactoring, knowing when to throw away;
courage to remove source code when obsolete
Respect: Respect for other as we as self-respect. For example, developers should
never commit changes that break compilation, that makes existing unit tests fail, or
that otherwise delays the work of their peers.

31. Feature Driven Development (FDD)
• Starts with a Domain Object Model and focus on OO
• Developed on real systems of Scale
• Eight Practices
1. Developing by Feature
2. Class Code Ownership
3. Feature Team
4. Inspections
5. Regular Build Schedule
6. Configuration Management
7. Reporting/Visibility of Results
31

32. Dynamic Systems Development Method
(DSDM)
1. Assume can’t build perfectly first time
2. 20% of time can deliver 80% of proposed system
3. Therefore focus on highest value – sounds like scrum, right?
4. Core practices
5. Time Boxing
6. MoSCoW prioritization
7. Modelling but only at user level
8. Prototyping – helps with understanding and awareness
9. Testing – focused on User no specifics on lower levels of
testing
10. Configuration Management – any increment is reversible 32

33. Agile Methods and Practices
33
http://www.versionone.com/pdf/7th-Annual-State-of-Agile-Development-Survey.pdf

34. Agile Succeeding
34

35. Agile Benefits Quantified
35

36. Agile And Lean Compared
36

37. Module 5
Deep Dive: SCRUM
37

38. SCRUM – How it evolved
38
• Takeuchi and Nonaka – coined in The New Product Development Game in 1986
• 1993 First Project Easel Corp by Jeff Sutherland, formalized by Ken Schwaber and Jeff
Sutherland in 1995
• 2002 Scrum Alliance formed
• It is now probably the fastest-growing approach to software development globally
• Used in many Fortune 100 companies globally
• Google • Sun
• Infosys • Wipro
• TCS • IBM
• Nokia • Lockheed-Martin
• HP • Agilent
• EMC • GE

39. SCRUM Definition
39
“ An agile framework that allows us to focus on delivering the highest
business value in the shortest time”
Mike Cohn

40. What is SCRUM?
40
• Incremental and Iterative
• High Level - Not prescriptive – although there are boundaries
• Emphasis on Collaboration
• Easy to understand – hard to execute
• Change as Opportunity
• Goal(s) oriented
• Empirical Process – Inspect and Adapt, Transparency
• Suited to Complex product development – cynefin framework, agile practices still
useful in other quadrants!

41. SCRUM is Not
41
1. Lacking Discipline – Inspection and Adaption, Just in Time Sprint and Release
Planning, XP engineering practices take discipline
2. Gantt chart detailed plan
3. Not a Silver Bullet – each project is different and has differing needs – but stick to the
core values and roles when applying it

42. Why SCRUM became popular
42
• More business value sooner
• Greater visibility
• Improved productivity and Discipline
• Less waste
• Higher quality
• Stronger teams with better morale
• Better return-on-investment for projects
• Visible Structure

43. SCRUM– An Overview
43

44. SCRUM Values
44

45. SCRUM Lifecycle
45

46. SCRUM Challenges
46
• It’s hard!
• It requires significant change
• Change in practices and skills
• Change in organization, planning, budgeting, HR
• Change in mindset and culture
• It makes all dysfunction visible
• Scrum doesn’t fix anything: we have to do it
• If we don’t address the problems, it will be painful
• Bad products will be delivered sooner, and doomed projects will fail faster
• Partial adoption may be worse than none at all
• Be forewarned: many Scrum adoptions fail!

47. SCRUM Roles
47

48. Pigs and Chickens
48

49. The SCRUM Team – Product Owner (PO)
49
• Owns vision for the product to be produced/released
• Creates and maintains the Product Backlog
• Final decision maker on prioritization of Product Backlog items

50. The SCRUM Team – SCRUM Master
50
• Facilitates implementation of the
process
• Builds self-organizing teams
• Removes team’s constraints and
impediments
• Protects the team from external
disturbances
• Empowers the team through Servant
Leadership
• Helps create visible Information
Radiators
• Coaches the team for successful
implementation

51. The SCRUM Team
51
• 7 people, +/- 2 – The Right Size
• Cross-functional team - includes
design, coding, testing, and other
resources required for potentially
shippable software
• Self-organizing and self-managing
• Inspect and Adapt through Daily
Scrum Meeting and Retrospective
• Assist PO to groom the backlog
• Plan the sprint
• Swarm over tasks – minimize Idle
work
• Musketeer attitude
• High bandwidth communications –
Face to Face always best
• Transparent, Focused (no more than 2
tasks), works sustainably, stays
together

52. Understanding the role of the Project
Manager
52

53. Agile Project Manager Responsibility
53
Ask the following questions
• How are Agile Projects Managed?
• Is the Scrum Master considered the Agile Project Manager?
• Who handles traditional project management responsibilities?
• Does this Scale?
Agile processes distribute the traditional project manager's responsibilities
• Task assignment and day-to-day project decisions –Team
• Responsibility for scope/schedule trade-offs - Product Owner
• Quality management – Team, Product Owner & Scrum Master
• Other traditional project management responsibilities - One or more of these
roles

54. Project Manager in SCRUM
54

55. Agile Teams
55
Staffing
• Team composition and interaction changes.
• Co-location of teams and or collaboration via
communication tools
• Roles and responsibilities of team members are clearly
defined
• Consider the use of an agile coach on the team

56. An Exercise in Responsibilities
56
ROUND 1: In a Non-Agile Environment
TEAM OTHER
PROJECT MANAGER

57. An Exercise in Responsibilities
57
ROUND 2: In an Agile Environment
TEAM OTHER
PROJECT MANAGER
SCRUM MASTER

58. 6 Time-boxed ceremonies
58
Daily Scrum
Sprint
Release
Planning
Sprint
Planning
Sprint Review
Sprint
Retrospective
How are we doing?
How often can we deliver?
What or how much do we do and when?
How do we do it?
How did we do it? Fit for purpose/use?
How do we do better? Inspect and Adapt
A timebox is a fixed period of time, during which something must be done.

59. Duration of Timeboxes
59
Maximum
Duration
For Sprints of 6
weeks
For Sprints of 4
weeks
For Sprints of 2
weeks
For Sprints of 1
week
Release
Planning
1.5 days 1 day ½ day 2 hours
Sprint Planning 1.5 days 1 day ½ day 2 hours
Sprint Review 6 hours ½ day 2 hours 1 hour
Sprint
Retrospective
6 hours ½ day 2 hours 1 hour
Daily Scrum 15 minutes 15 minutes 15 minutes 15 minutes
These are the maximum durations of each timebox. Meetings may adjourn early, if
the agenda is completed before the allotted time

60. SCRUM Artifacts
60
• User Stories
• Product Backlog
• List of functional & non-functional
requirements
• Sprint Backlog
• Prioritized list of stories for a
given Sprint
• Sprint Burndown Chart
• A chart showing completion of
stories over time
• Release Burndown Chart

61. SCRUM – Putting It All Together
61

62. 3 Key Tenets: Deliver-Empower-Adapt
62
1. Deliver Early & Often
Delivering a fully completed increment every time (sprint). This allows
stakeholders to enjoy the business benefits early rather than waiting for
the full life-cycle.
2. Empower your teams
Innovation does not come from compliance. Those doing knowledge
work are best qualified to organize that work. Scrum requires teams to
enforce professional boundaries, so they can achieve results
3. Inspect and Adapt
High performing teams are those that adjust their work to meet the
current reality. Scrum offers both quantitative and qualitative
techniques to assess how we can avoid disaster and improve
performance

63. Module 6
Deep Dive – Lean Methodology
63

64. Defining Lean
64
• Lean is a continuous improvement methodology
focused on managing processes, and improving them by
compressing time, rather than sweating assets
• Application of principles and techniques to eliminate
waste and improve efficiency of the process
• Focuses on flow, the value stream and eliminating
muda, the Japanese word for waste
• It is production of goods using less of everything
• Was generated from the Just-in-time (JIT) philosophy
of continuous and forced problem solving. JIT enables
making components available where they are needed
when they are needed, just at the time when needed.

65. Historical Perspective
65
• Underpinning of Lean Philosophy is that an organization must leverage the
knowledge and brain power of every employee to help the company change for the
better everyday to meet its goals.
• Toyota Production System – 1948 - 1975
• Developed by Taiichi Ohno, Shigeo Shingo and Eiji Toyoda
• Toyota produces automobiles for the general public of Japan
• Implemented JIT based production
• Toyota became one of the top 10 companies in the world
• 2007 - became the largest car manufacturer
• Focused on eliminating three kinds of waste
• Muri
• Mura
• Muda

66. Types of Waste
66
MUDA
Any activity that consumes resources
without creating value for the customer.
Unneeded processes or steps:
• Using expensive tools instead of simpler
ones
• Having meetings when not required
• Excessive paperwork
• Duplication of work
MURA
Unevenness, irregularity or Inconsistency in an
operation
MURI
Overburdening of equipment, facilities, people
caused by Muda and Mura Pushing people or
equipment beyond allowed limits

67. Lean Principles
67

68. The 7 Wastes
68
Wastes in
Manufacturing
Wastes in Software
Development
Inventory Partially Work Done
Extra Processing Paperwork or extra
documentation
Over Production Extra Features
Transportation Building the Wrong
Thing
Waiting Waiting for
Information
Motion Task Switching &
Motion
Defects Bugs

69. 7 Principles of Lean Software
Development
69
1. Eliminating waste
2. Build quality in
3. Create knowledge
4. Defer commitment
5. Deliver fast
6. Respect people
7. Optimize the whole

70. Implementing Lean Techniques
70
Identify Pull
Map the
Value Stream
Create FlowEstablish Pull
Seek
Perfection

71. Value Stream Mapping
71
• It is the process of identifying and charting the flow of information, processes, and
goods or services across the entire supply chain from the supplier to customer possession
• Includes both value-added and non value-added activities
• Allows for “seeing” areas of waste in current state
• Enables you to remove waste and improve cycle time and efficiency

72. How People Benefit From Lean
72

73. How Customers Benefit From Lean
73

74. Module 7
Applying SCRUM and Lean for Non-IT Projects
74

75. Applying SCRUM to Construction
Industry
75

76. Applying SCRUM to a Sales Scenario
76
• Current Organization Challenges:
• Update on sales opportunities and status updates is weekly and bi-weekly
• Resources are working on low value deals or non-deal closing activities
• Teams losing focus and randomized due to multiple directions
• Reactive decision making leading to delays and lost opportunities

77. Applying SCRUM to a Sales Scenario
77
• Backlog
• Deals to be closed this quarter
• Deals to be developed in the following quarters
• User Story
• Objective goals to be achieved
• Tasks
• Activities identified to achieve the targets
• Impediments
• Challenges / Issues blocking progress
• Release
• Target Sales Volume / Numbers
• Sprint
• Month / Quarter
• SCRUM Master
• Sales Manager

78. Applying SCRUM to a Sales Scenario
78
• List of sales objectives to be achieved forms the Product Backlog
• Developing a quarter by quarter sales plan maps to the Release Plan to get the
product out.
• The immediate quarter’s target maps to the Sprint Plan
• A daily standup meeting of 30 minutes is held with the Sales team to take status
update and discussing impediments, followed by another 30 minutes of prioritization
discussion
• The Sales Manager acts as the SCRUM master during the Standup Meeting to help his
team by removing the impediments and providing them with all the resources and
support. He will also work closely with the management to ensure that the team does
not get randomized and remain focused.
• Embrace change and adapt
• Empower the team to speak-up and communicate and facilitate team decision making.

79. Applying Lean Principles to Construction
Industry
79
Lean Construction is an adaption of Lean principles and practices to design and execution of
construction projects. Lean construction supplements traditional construction management
approaches by focusing on:
1. Creating material and information flows
2. Maximizing value generation
3. Using plan, execute and control paradigms
Although Lean Construction shares many principles with Lean Production, it is different in how it is
practiced.
Shared Principles:
1. Optimization of entire system through collaboration and systematic learning
2. Continual improvement and pursuit of perfection involving everyone in the system
3. Focus on delivering value desired by the owner/client/end-user
4. Creating flow by eliminating obstacles to value creation and elimination of processes that create no
value
5. Creating pull production
Differences:
1. Construction projects are unique.
2.Multiple contractors/suppliers act under different commercial arrangements
3.Construction environments are typically outdoors and/or difficult to control
4.Communication challenges caused by teams being geographically separated

80. Module 8
Requirements Management
80

81. Creating and Managing a Product
Backlog
81
• A backlog contains a broad list of descriptions of all required features, wish-list items,
etc. prioritized by business value. It is the “What” that will be built.
• It contains rough estimates of both business value and development effort.
• Product Owner is in charge of defining priorities in the Product Backlog
• Maintain Story Lists

82. Creating and Managing a Product
Backlog
82

83. Creating and Managing a Product
Backlog
83

84. Techniques for Requirements Gathering
84
• Brainstorming, Interviews
• Prototyping – Create screen prototypes for clear requirements
• Functional Modelling
• Use Cases (Scenario-driven approach) and Storyboards
• User Stories

85. User Stories
85

86. Principles of User Stories - The 3 C’s
86

87. Principles of User Stories – Types of
Stories
87
Theme:
• A set of related user stories that may be combined together and treated as a single
entity for either estimating or release planning
• A Theme is kept for ease of estimation and planning
• Example: Support for Database will involve defining schema, migrating existing data,
creating reports and so on
Epic:
• Large user stories with low priority and too big to implement in one iteration
• Broken down further into smaller user stories and the lower level child stories are
assigned priorities for planning
• An Epic, by its very size alone, is often a Theme!

88. Principles of User Stories – Types of
Stories
88

89. User Story Example
89
As a customer service rep., I can search for a customer so that I can view his/her
account details.
• When searching by a valid account number, the account is shown
• When searching by a valid name and SSN, the account is shown
• If no results are found, show appropriate message
• Acceptance tests?

90. User Story Attributes - INVEST
90
Every user story (requirement) should meet the below
criteria (INVEST acronym) for it to be considered complete:
• Independent
• Negotiable
• Valuable (to users/customers)
• Estimate-able
• Small
• Testable

91. Non-Functional Requirements
91
• Write a story for them
• They can also become part of the Definition of Done.
• e.g.: Internationalization would affect all stories in some way.
• Other stories
• Knowledge Acquisition Stories – e.g.: explore a new technology, spike solution
• Technical Stories – e.g., set up DB table

92. Gathering User Stories - Workshop
92
• User Story Workshop
Product Owner, Scrum Master and Development Team together with
stakeholders to build detailed requirements
• Story Mapping (Jeff Patton)
• Decompose High Level Activity into a workflow with further
decomposition into tasks
• Divide into a hierarchy of Themes, Epics and Stories
• Workflows are useful even if not doing the technique explicitly
• Natural prioritization can emerge

93. Gathering User Stories – User Story
Mapping
93
Story Mapping (Jeff Patton)
• Decompose High Level Activity into a workflow with further decomposition into
tasks
• Divide into a hierarchy of Epics, Themes and Stories
• Workflows are useful even if not doing the technique explicitly
• Natural prioritization can emerge

94. User Story Smells
94
• Interdependent Stories
• Gold Plating
• Too Many Details (not INVEST)
• Thinking Too Far Ahead (waterfall mindset)
• Language Issues
• Business Dominated – concepts not understood by
Developer
• Developer Dominated – too much technical jargon

95. User Story Splitting
95
• A story may not fit within an iteration, it’s too large to estimate (epic)
• Examples (from Mike Cohn – Agile Estimating and Planning)
• Split by Data Boundary.
• As a borrower, I want to pay off my loan
• As a borrower, I want to pay off my loan without overpayments
• As a borrower if I accidently repay too much, I get a refund if it’s
over 2??
• Split by Operational Boundaries – C.R.U.D.
• Cross cutting concerns, e.g. logging can be another user story

96. Backlog Prioritization
96
Agile Prioritization Technique - MoSCoW
Must have (or Minimum Usable Subset)
Should have
Could have
Won’t have (but Would like in future)
‘Must Haves‘ are features that must be included before the product can be launched. It is
good to have clarity on this before a project begins, as this is the minimum scope for the
product to be useful.
‘Should Haves‘ are features that are not critical to launch, but are considered to be
important and of a high value to the user.
‘Could Haves‘ are features that are nice to have and could potentially be included
without incurring too much effort or cost. These will be the first features to be removed
from scope if the project’s timescales are later at risk.
‘Won’t Haves‘ are features that have been requested but are explicitly excluded from
scope for the planned duration, and may be included in a future phase of development.

97. Minimal Marketable Features - MVP
97

98. Velocity
98
Measuring Velocity
Fully “done, done” story points are counted
Partially completed stories do not count at all
• Don’t imply precision by saying you completed 4.7 points out of 8
• That last 10% can take 90% of the time
• The business value is not achieved until it is done, done (or do smaller stories)
The actual velocity of the last two iterations is the planned velocity of the next

99. Module 9
Estimation
99

100. Agile Estimation
100
• What are some of the traditional techniques you are aware of?
• What are you estimating?

101. Traditional Estimation Techniques
101
• Count/Compute/Judge
• Calibrate & Historical Data
• Individual Expert Judgement
• Decomposition & Recomposition
• Estimation by Analogy
• Expert Judgement in Groups: e.g. Wideband Delphi
Source: “Software Estimation: Demystifying the Black Art” by Steve McConnell

102. Estimation “Best” Practice
102
Size Effort
Schedule
Cost
Features

103. Challenges
103
Size Effort
Schedule
Cost
Features
• No perfect measure of size
• Do we measure in Lines of code, Function points, Story points?
e.g., 10K LOC

104. Challenges
104
Human Influences can make a 14x difference in total project effort/cost according to
Cocomo II (The Constructive Cost Model)
Eg: 10K LOC
Eg: 10 person months

105. Challenges
105
Size Effort
Schedule
Cost
Features
Eg: 10K LOC Eg: 10 Staff months Eg: 6 months duration
Schedule In Months = 3.0 x Staff months1/3
Need to cater for many overheads
e.g.: holidays, full time/part time, dependencies

106. Agile Delivery – Doesn’t Estimate
Schedule
106
Size Effort
Schedule
Cost
Features
Agile Delivery estimates size in story points or ideal hours & over iterations. Team
capacity and velocity drives schedule.

107. Story Points
107
• Measure of Complexity - A simple way to estimate level of effort expected for a Story
based on size and complexity
• Estimate of Size, not Duration Estimates are based on size, not duration (derived
empirically once Iterations have started)
• Relative Weighting Story points are a relative measure (research has shown humans
are better at this)
• Additive Puts estimates in units that can be added together (unlike time-based
estimates!)
• Constrained to Set of Values Often scored on a scale based on Fibonacci Numbers (0,
1, 2, 3, 5, 8, 13, 20, 40, 100)

108. Planning Poker
108
An iterative approach to estimating Steps:
• Each estimator is given a deck of cards, each
card has a valid estimate written on it
• Customer/Product owner reads a story and it’s
discussed briefly
• Each estimator selects a card that’s his or her
estimate
• Cards are turned over so all can see them
• Discuss differences (especially outliers)
• Re-estimate until estimates converge

109. Agile Estimation - Workflow
109

110. Planning Poker – Why It Works
110
• Multiple Experts - Delphi Method
• People doing the work are best placed to estimate it
• Generates a lively debate - Consensus
• It’s fun!
• Let’s try it - curiosity

111. Let’s Play Planning Poker
111
• We are having a massive party
• Lots to prepare!
• Want to make a large fruit salad
• Never made one before...
• What can we do in time?

112. Starting Point
112

113. Estimation Techniques
113
Consider
• Risk (sharp knife, spiky/slippery skin)
• Effort (size of fruit)
• Complexity (cutting difficulty)
• Relativity (to existing estimates)
Definition of Done
• All seeds removed (except strawberry
& banana)
• All fruit to be washed
• Bite-sized pieces
Acceptance Criteria
• Rockmelon, banana, mango, coconut,
pineapple skin off
• Pear, apple skin on

114. Velocity Chart
114

115. Relative Sizing
115

116. Determining Team Velocity
116

117. Determining # Sprints To Complete
117

118. Module 10
Project Planning
118

119. Have A Vision
119
• Establish the vision for the product - concise
to the point
• Examples
• Elevator Statement – can you state
the
goal in a 30 second elevator ride
• Product Datasheet – do the one
pager
• Product Vision Box – Draw the box
the
product ships in
• Conference Slides – two, three slides
not bullet points
• Press Release – imagine the press
release you’d create – write it down
• Magazine Review – a fictitious review
of the product

120. SCRUM Planning
120

121. Release Planning
121

122. Release Planning
122
Refer : http://www.scmpatterns.com/pubs/crossroads-mirror/2008-05-CMCrossroads.pdf

123. Release Planning
123

124. Sprint Backlog
124

125. Sprint Planning
125

126. Sprint Planning
126

127. Sprint Planning – Best Practice
127

128. Typical Project Plan
128

129. Module 11
Project Execution & Tracking
129

130. Daily Standup (SCRUM) Meeting
130
Goal
• Enable to team to share progress with each other
• Make visible blocks (impediments) daily for whole team to see
Everyone stands in a circle and reports 3 things
• What did I do since the last Daily Scrum Meeting?
• What will I try to do by the next Daily Scrum meeting?
• What are my blocks?
15 minutes maximum
No discussion or debate: listening only
• After meeting ends, discuss and problem-solving can start
Team and ScrumMaster only
• Team can invite PO or others if they wish, but it’s up to the team
After the meeting, ScrumMaster leads the removal of blocks

131. Information Radiator
131
• Was coined by Alistair Cockburn
• Graphical Representation of Project Status & Key aspects displayed in Team
Workspace
• Current iteration’s work set ( user stories)
• Current work assignments
• Number of tests written, passed, failed
• Number of user stories delivered
• Status of key servers
• Results of actions from previous retrospective
• Keeps team focused on tasks and actions needing priority and attention
• Helps drive transparency across the organization

132. A Burndown Chart
132

133. Sprint Burndown
133

134. Sprint Burnup Chart
134

135. Release Burndown
135

136. Sprint Review
136

137. Sprint Retrospective
137

138. Techniques for Sprint Retrospective
138
• Post-it brainstorming
• Dot voting
• Timeline
• Team Radar

139. Sprint Retrospective – An Example
139
Suggested Topics
• What went well, What could be better,
What will we do about it
• What should we continue doing, What
should we start doing, What should we stop
doing
Suggested Tools
• Whiteboards, Flipcharts, Index Cards, Sticky
Notes
Team mind-map exercise to understand relationships of project issues

140. Module 12
Agile Adoption
140

141. Your First Agile Pilot Project
141

142. Best Practices
142
Easy and continuous access to resources
• Source code repository (Bitbucket, Github, etc)
• Continuous Integration Server (Jenkins, Bamboo, etc)
• Bug Tracking tool (JIRA, Bugzilla, etc)
• Wiki (Confluence, etc)
• Project Management Tool (JIRA, etc)
Setup infrastructure to support team member communication
• Sprint meetings
• Offline discussions
• Knowledge sharing sessions
Regular people movement for short periods
• Mixing of people to overcome cultural issues, etc.,
• One Team feeling

143. Making Agile Adoption Successful
143
• Use a Physical Board or Good Software
• Start collecting and using statistics
• Engage a coach / consultant
• Action over talking
• Give everyone training and start group-wide discussions
• Enthuse, Pull, don’t PUSH
• Be clear on Why
• Process and Technical , adopt technical side as well as process side
• Get Product Management / Owner Flow to developers clear and clean
• Structure changes – Functional groups

144. SCRUM in Action
144
Scrum Meetings
• Sprint Planning
• Daily Stand Up
• Sprint Review
• Sprint Retrospectives
Co-Located Teams
• Easier communication &
collaboration
• Sprint execution comparatively easier
Distributed Teams
• Teams with some overlapping time
period
• Teams with no overlapping time
period

145. Watch the Live Demonstration
Watch the recorded webinar here!

146. Recommended Courses
NetCom Learning offers a comprehensive portfolio for Agile Project
Management training options. Please see below the list of recommended
courses:
Agile Project Management
Managing Agile Projects Using TFS 2017
PMI Agile Certified Practitioner (PMI-ACP)®
Check out more Agile Project Management training options with NetCom
Learning – CLICK HERE

147. Our live webinars will help you to touch base a wide variety of IT, soft skills and
business productivity topics; and keep you up to date on the latest IT industry trends.
Register now for our upcoming webinars:
5 Practices of Exemplary Leadership – May 04
A Deep Dive in the World of IT Networking (Part 1) – May 09
How to Manage & Secure Data with Microsoft Datacenters?- May 11
VMware vCenter 6.5 Consoles and Connections – May 15
Office 365 on any Platform (Windows, Mac, Mobile/Tablet) – May 18

148. Special Promotion
Whether you're learning new IT or Business skills, or you are developing a learning plan for
your team, now you can register for our Guaranteed to Run classes with confidence.
From Microsoft, to CompTIA, to CISSP; all classes delivered by top-notch instructors in in-
person Instructor-led Classroom or Live Online.
Learn more»

149. To get latest technology updates, please follow our social media pages!

151. THANK YOU !!!
We manage learning.
“Building an Innovative Learning Organization. A Framework to Build a
Smarter Workforce, Adapt to Change, and Drive Growth”. Download now!