Agile Training Ver 2.4

Agile Methodology Training
Copyright © 2019 Tech Mahindra. All rights reserved. 1

Table of Contents
 Introduction to Agile Methodology
– Why Agile or need for Agile Methodology
– Agile Principles
– Agile vs. Traditional Approach

– Project Constraints
– Agile Manifesto/Myths
– Agile methods - Scrum, XP, DSDM, RUP
 Scrum Framework
– Introduction to Scrum Framework
– Scrum Roles and Responsibilities

– Scrum Work Products
– Sprint Planning in Scrum
– Ceremonies in Scrum
 Implementation of Agile @ Tech Mahindra

Typical Waterfall Project Lifecycle
Typical Events:
Requirement • Gather user requirements and Analyze
Analysis • Prepare detailed(?) Use Case documents • Meetings
• Status Reporting
• Escalations
• Reviews and Rework
• Discovery of new
Design • Software Architecture scope
• Missed deadlines
• Missed deliverables
• Celebrations
Development • Coding, Unit Testing
Testing • Testing, Integration Testing
Typical Roles:
• Developer
• Tester
• Team Leader • Code deployment
Deployment
• Business Analyst
• Project Manager
• Senior Project Manager
• ….
• ….
• CTO Maintenance
• …..
• CEO

Introduction to Agile Methodology

WHAT HAPPENS ??
What happens if the client asks to add new changes after design is all complete?
What happens if in midway a developer comes up with an innovative way of doing things?
What happens of the competitor is releasing the same kind of product 1 month earlier?
What happens if the Competitor has come up with new advanced features?
What happens if in between market demands changes?
What happens if client’s budget scenario changes in-between?
What happens if a survey shows the current features are not well accepted in market by
users?
What happens if the client says this is not what he wanted after its showcased to him?
What happens if the priority of requirements changes based on market and users?
What happens if in-between, there is a conflict in understanding of the developers than of
the providers?
These scenarios reflects the CHANGING TIMES w.r.t. market and user demands.
AGILE Methodology addresses all the above.

Need for Agile Methodology
 Time To Market (TTM) becoming crucial
 Budgets are shrinking
 Requirements not clear upfront or being developed concurrently
 Agile Project Management methods like Scrum, Extreme
Programming, Lean Development, etc.. can be applied to any
project effort to deliver improved results in ever evolving business
needs, and do so in a manner that demonstrates visible,
predictable progress toward today’s most important business
priorities.
Agility is the ability to both create and respond to change in

order to profit in a turbulent business environment.
- Jim Highsmith, Agile Project Management

Sunrise of Agile Methodology
 In late 1990's several methodologies began to get increasing public
attention.
 They all emphasized

 close collaboration between the programmer team and business experts;
 face-to-face communication (as more efficient than written documentation);
 frequent delivery of new deployable business value;
 tight, self-organizing teams;
 and ways to craft the code and the team such that the inevitable
requirements churn was not a crisis.
 Early 2001 saw a workshop in Snowbird, Utah, USA, where various
originators and practitioners of these methodologies met to figure out just
what it was they had in common.
 They picked the word "agile" for an umbrella term and crafted the
Manifesto
Agile Manifesto
• We are uncovering better ways of developing software by doing it and helping
others do it. Through this work we have come to value: (www.agilemanifesto.org)
Individuals and Interactions over Processes and Tools
Working Software over Comprehensive Documentation
Customer Collaboration over Contract Negotiation
Responding to Change over Following a Plan

Principles behind the Agile Manifesto
 Our highest priority is to meet the customer requirements through early and
continuous delivery
 Welcome changing requirements, even late in development
 Deliver working software frequently, from a couple of weeks to a couple of
months
 Business people and developers must work together daily throughout the project
 Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
 The most efficient and effective method of conveying information to and within a
development team is face-to-face communication
 Continuous attention to technical excellence and good design enhances agility
 At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly

Agile Vs Traditional Waterfall approach

Project Constraints
Traditional Approach Agile Approach
 Time and Cost is variable  Focus on Quality and Value

 Quality at Risk  Manage Changes to Features
 Deliver Within Time and Cost

Cost of Change Curve
Agile Waterfall

Agile Myths
 Myth : Implementing Agile is easy
 Myth : Agile gives instant benefits
 Myth : Agile means no documentation
 Myth : Agile means poor quality
 Myth : Agile is a silver bullet
 Myth : Agile is new
 Myth : Traditional delivery never works
 Myth : Agile replaces everything that has gone before
 Myth : Agile means no planning

Benefits of Agile
Agile
Agile
Satisfaction
Traditional
Traditional
Agile
Traditional
Agile

Agile Methods
Method Key Points Special Features
Independent, small, self-organizing
Enforce a paradigm shift from the “defined
development teams, 30-day release
Scrum and repeatable” to the “new product
cycles. Most used and popular along
development view of Scrum”.
with XP
Extreme Programming (XP) - Refactoring – the ongoing redesign of the

XP Customer driven development, small system to improve its performance and
teams, daily builds responsiveness to change
Dynamic Systems Development

Method (DSDM) - Application of First truly agile software development
controls to RAD, use of time boxing, method, use of prototyping, several user
DSDM empowered DSDM teams, active roles: “ambassador”, “visionary” and
consortium to steer the method “advisor”
development
Rational Unified Process (RUP -
Complete software development
RUP model including tool support. Activity
Business modelling, tool family support
driven role assignment

Sailing Two Boats
 Many Projects attempt to use both Waterfall and Agile Project Management
Methodologies to deliver projects
 Waterfall + Agile = Hybrid Project Management
 In such cases, typically, the development phase of the projects are proposed
as Sprints and planned accordingly.
 Testing phase is kept separately
 Delivery dates must be followed as per Waterfall Project Methodology
 Scope may creep – just like in Agile, but time/cost does not expand - Waterfall
way!! 

SCRUM FRAMEWORK

History of Scrum
 The term Scrum comes from 1986 study by Takeuchi and Nonaka “The New Product
Development Game”, published in Harvard Business Review
 “The… ‘relay race’ approach to product development…may conflict with the goals of
maximum speed and flexibility. Instead a holistic or ‘rugby’ approach—where a team tries
to go the distance as a unit, passing the ball back and forth—may better serve today’s
competitive requirements.” Hirotaka Takeuchi and Ikujiro Nonaka
In IT context, it is Project Management Methodology for Agile development.

Scrum Framework
Scrum is a framework within which people can address complex adaptive problems, while
productively and creatively delivering products of the highest possible value.
 Scrum is not a methodology, but a framework.
 Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts
that knowledge comes from experience and making decisions based on what is known.
 Scrum employs an iterative, incremental approach to optimize predictability and control risk.
Scrum in Action - Planning through Software Delivery

Transparency
Scrum Foundation The process must be visible to

those responsible for outcome.
Scrum
Inspection
Transparency
Scrum users must

frequently inspect
Inspection
Scrum artifacts and
Adaption
progress towards a
Sprint Goal to detect
undesirable
variances.
Adaption
If an aspect of a process
deviate outside acceptable
limits resulting to unacceptable
product, the process must be
Empiricism adjusted. An adjustment must

be made as soon as possible to
minimize further deviation.

Scrum Components
• Product Owner • The Sprint
• Scrum Master • Sprint Planning
• Development Team • Daily Scrum
• Sprint Review
• Sprint Retrospective
Scrum
Events
Team
Artifacts Values
• Product Backlog • Courage
• Sprint Backlog • Focus
• Increment • Commitment
• Respect
• Openness

Scrum Values

Talking Point
 Question:
What is the role of Management in Scrum?
 Potential Answers:
A) Continually monitor staffing levels of the Development Team.
B) Monitor the Development Team's productivity.
C) Support the Product Owner with insights and information into high value product and
system capabilities. Support the Scrum Master to cause organizational change that
fosters empiricism, self-organization, bottom-up intelligence, and intelligent release of
software.
D) Identify and remove people that aren't working hard enough.

Answer and Feedback
 Correct Answer:
C) Support the Product Owner with insights and information into high value product and
system capabilities. Support the Scrum Master to cause organizational change that
fosters empiricism, self-organization, bottom-up intelligence, and intelligent release of
software.
 Feedback:
Management has no active role in the actual product development through Scrum.
However, management external to the Scrum team is incredibly important in setting the
vision and strategy to guide the overall direction of the organization.

Scrum Team

Product Owner
• Product Owner (PO) is responsible for maximizing the value of the product
• PO is the sole person responsible for managing the Product Backlog.
• As a part of Product Backlog Management, below is taken care by PO:
• Clearly expressing Product Backlog items
• Ordering the items in the Product Backlog to best achieve goals and missions
• Optimizing the value of the work the Development Team performs
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum
Team will work on next; and
• Ensuring the Development Team understands items in the Product Backlog to the level needed.
• PO may choose to manage the Product Backlog on his own or may choose to get the
Development Team do on his behalf, however PO remains the sole accountable person
to do so.
• The Product Owner is one person, not a committee.
• For Product Owner to succeed, the entire organization must respect his or her decisions.

Scrum Master
• Scrum Master is responsible for promoting and supporting scrum in the team and organization
• Scrum Masters promotes scrum by helping everyone understand Scrum theory, practices, rules, and values
• Scrum Master helps those outside the Scrum to understand which interactions are helpful with Scrum Team
and which one’s are not.
• The Scrum Master teaches the Scrum Team to keep the interactions/meetings within the time-box.
• The Scrum Master ensures that the meeting is positive and productive.
As a servant-leader and facilitator, Scrum Master serves below stakeholders in several ways, including:
Product Owner Development Team Organization
• Ensuring that goals, scope, and product domain • Coaching the Development Team in self- • Leading and coaching the organization in its
are understood by everyone on the Scrum Team organization and cross-functionality; Scrum adoption;
as well as possible • Helping the Development Team to create high- • Planning Scrum implementations within the
• Finding techniques for effective Product Backlog value products; organization;
management • Removing impediments to the Development • Helping employees and stakeholders understand
• Helping the Scrum Team understand the need for Team’s progress; and enact Scrum and empirical product
clear and concise Product Backlog items • Facilitating Scrum events as requested or • development;
• Understanding product planning in an empirical needed; and, • Causing change that increases the productivity of
environment • Coaching the Development Team in the Scrum Team; and,
• Ensuring the Product Owner knows how to organizational environments in which Scrum is • Working with other Scrum Masters to increase the
arrange the Product Backlog to maximize value not yet fully adopted and understood. effectiveness of the application of Scrum
• Understanding and practicing agility; and, • in the organization.
• Facilitating Scrum events as requested or
needed.

Development Team
• The Development Team consists of professionals who do the work of delivering a potentially
releasable increment of “Done” product at the end of each Sprint.
• A “Done” increment is required at the Sprint Review.
• Only members of the Development Team create the Increment.
• Development Teams are structured and empowered to organize and manage their own work.
• The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.
• Development Teams have the following characteristics:
• They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product
Backlog into Increments of potentially releasable functionality
• Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment
• Scrum recognizes no titles for Dev Team members, regardless of the work being performed by the person
• Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed
like testing, architecture, operations, or business analysis; and
• Individual Development Team members may have specialized skills and areas of focus, but accountability
belongs to the Development Team as a whole.
• Ideal team size is between 3 to 9. Fewer than 3 team members team limits interaction, and larger than 9 team
members makes coordination challenging.

Talking Point
 Question:
Below are the activities that each and every Scrum Master MUST perform:
– Arrange meetings (or book meetings rooms) for Developers and/or Product Owner
to discuss technical, functional or coding related issues/discussions
– Typing notes and sending Minutes of Meeting (MoM)
– Taking status updates in Daily Standup Meeting
– Enact Team Mom/Dad – asks developers every now-and-then about work progress
– Must attend Daily Scrum

– Not collecting the data(observations) during Sprints and not discussing in the
Retrospective
A) False
B) True
Answer and Feedback
 Correct Answer:
A) False
 Feedback:
Scrum teams have individuals who are committed, specialists, cross-functional,
collaborative, independent, forward-looking, go-getters!!
Scrum Masters are facilitators, enablers, catalysts rather than doers on behalf of others.
They are the observers, and share their findings during Retrospective sessions so that
team can improve by tuning the processes.

Scrum Artifacts

Artifact Transparency
 Artifact Transparency is achieved by using highly visible progress
information radiators or Big Visible Charts(BVC)
 Displays key information about the project/mission
 Everyone can see All the Information
 Prominently on Walls, Whiteboards, Agile Tools, etc..
 Typical Contents:
 Task Board
– Story
– Tasks and their statues
– Impediments - Risks, Issues, Actions
– Burn down/Burnup Chart – where maintained
 Agile Tools
– JIRA, Azure DevOps, Trello, etc.
Copyright
Backlogs
© 2019 Tech Mahindra. All rights reserved. 32
Product Backlog
 Product Backlog is a living business
requirements document; continuously
evolves to respond to business needs
REQ 1 REQ 2 REQ 3
 The Product Owner - based on the

feedback from business stakeholders -
creates various Product Backlog Items
 A queue of Work Items for Scrum Team

 Once the Product Backlog is formed,
Product Owner helps preparing the
Release Plan - product delivery plan
 Release Planning includes selection of

features to be Released in a particular
Release
REQ N  Owned and ordered/prioritized by

Product Owner only – development
team may help with technical feasibility

Sample Product Backlog / Release Plan

Sprint Backlog
New Business  Based on Product Owner’s priorities, the
Circumstances development team selects the Product
Backlog Items (PBI) as a forecast of a
potentially releasable increment – called
New
Requiremen
Bug fixes
Sprint Backlog
ts Enhanced
Product
 Tasks of the PBI’s evolves during the
sprint – new tasks added as needed,
Product Backlog
tasks removed if no longer relevant
Items via PB Review
Product Increment(s) via  Visible all the work for transparency

Release Mgmt. Process
Product Backlog
 Includes at least one high priority

> Requirement 1
> Requirement 2
> Requirement 3
Sprint Backlog
process improvement identified in the
(Ordered List of
Tasks previous Retrospective meeting.
Product Backlog
Items)
 Only the Development Team can change
its Sprint Backlog during a Sprint.
Prioritized Items
In Sprint Planning
 The Sprint Backlog is a highly visible,
real-time picture of the work that the
Development Team plans to accomplish
during the Sprint, and it belongs solely to
the Development Team.
Sample Sprint Backlog

Increments
 An Increment is the sum of all the Product Backlog items completed during a
Sprint and the value of the increments of all previous Sprints.
 At the end of a Sprint, the new Increment must be “Done,” which means it
must be in useable condition and meet the Scrum Team’s definition of “Done.”
 E.g. if there are application integrations, then those must be working too
as there are no separate testing stages like System testing, Integration
testing, Regression Testing, etc. are applicable.
 The increment is a step toward a vision or goal.
 The increment must be in useable condition regardless of whether the Product
Owner decides to release it.
 Potentially releasable increment – meaning if the Product Owner wishes,
the increment should be readily deployable to target environment without any
further work.
Scrum Myths
Myth Clarification
Burn Down/Up Charts A graphical representation of work left to do versus time. The outstanding work is often on
should be used the vertical axis, with time along the horizontal.
Scrum does not mandate to use burn down/up charts to track the progress. For reporting
purposes, the Product Owner may choose the best possible mechanism he thinks best
suits.
Story Points and Velocity Velocity is a measure of the amount of work a Team can potentially tackle during a single
to evaluate the Sprint.
amount/quantity of work
Story Point and velocity is one of the ways of determining the quantity of work. In
practice, stakeholders found man-hours much more convenient.
Theme/Epic/User Story Scrum does not mandate how to write an Product Backlog Item. A Theme/Epic/User
Story are some of the ways of representing user/business needs, not the only ways.
Epic – a set of logically grouped user stories/functionalities

No Project Manager Project managers responsibilities are spread across Scrum Team members i.e. to Product
Owner, Scrum Master, Developers.
Release Planning Scrum does not directly address Release Planning. Instead, the framework ensures that
the potentially releasable working product is always available to be made as a part of the
requisite release. Product Owner deals with stakeholders (business and development
teams) and manage releases.
Testing Sprints There are no separate Sprints for any type of Testing – system/integration/regression.
Each sprint must produce a potentially releasable increment.

Sprint Planning in Scrum

What is a Sprint?
 Sprint is a time-box having fixed length of period from 2 Weeks to 4 weeks (1
Month); depending upon Release Cycle
7 Days 30 Days
 Each Sprint always has Same Duration
 Back To Back – No Gaps Between Sprints
 Creates ‘A Potential Shippable Product Increment’ at the end of each Sprint
 Could be delivered to ‘Live’ if Product Owner demands so
Shorter Release Cycles = Shorter Sprints

 Sample Sprint Backlog

Sprint Planning
 Strictly Time-Boxed Meetings … Max 8 hours for 4 weeks of sprint
Facilitate & Time
Draft Sprint box the Meeting
Backlog
(Stories)
Scrum Sprint
Team
Master Goal
Capabilities
Explain Goal,
Business Vision & Backlog
Conditions Items
Product
Technology
Stability
Owner Sprint
Plans & Commit
Backlog
Retrospective to work on
Backlog Items
Developers
Testers
Sprint Planning Meeting
 Product Owner
– The Product Owner describes highest priority features to the Team.
– Selects the ideal backlog for the upcoming sprint and communicates its
meaning and importance to team
– Answers questions but does not direct the team’s choices.
 Development Team
– Decides what they can commit to delivering in a Sprint.
– Would seek clarifications from Product Owner
– Decides on how much it can commit to delivering in the Sprint
– The outcome is the Sprint goal and the Sprint Backlog.
 Scrum Master
– Facilitates the Sprint Planning sessions, and teaches everyone to keep it
time-boxed
 Sprint Goal
– An objective to be met within Sprint, and guidance to Scrum Team why it is
building an increment
– © 2019
Copyright Crafted together
Tech Mahindra. and in agreement by Scrum Team
All rights reserved. 42
Examples of Sprint Goals

Multi-Level Planning
Release Plan Typically Every 3 or 6 Months
Sprint Plan
Typically Every 2 or 4 Weeks
Daily Plan Daily at Scrum Meetings

Estimation

Estimating Size
► Traditional and Agile measure size differently
 Traditional Measures of Size  Agile Measures of Size

 Lines of Code  Ideal Time
 Function Points  Story Points
 Influenced by experienced/seniors  Developer Team decides
 Releases are estimated ‘Top-Down’

 Experience Based
 Generally 2 approaches used-
 Ideal days – A Day Without Any Real World Interruptions
 Story Points – Relative Estimation – More Popular
 Non Numerical comparison not as good

Estimating Size – Ideal Days & Story Points
 Ideal Days
– Removes the Likely Real World Interruptions
– 50% - 80% Productive is Common Assumption
– Ideal Days are Easy to Explain and Can be used for Longer Term Estimates
– But My Ideal Day May Not Be Your Ideal Day
 Story Points
– The “bigness” of a task
– Influenced by:

How hard it is

How much of it there is
– Relative values are what is important
 A login screen is a 2
 A search feature is an 8
– Teams can Deliver a Certain Number of Story Points per Sprint
– It is Quicker and Easier than Ideal Days

Approaches to Estimation
 Estimates are put-forward by a GROUP (Development Team) not an
INDIVIDUAL
 Use a consistent relative scale
 Combine techniques
 Expert Opinion
 Analogy-
 Comparing an un-sized story to previously sized stories
 Compare the story to multiple previously sizes stories – not just one
 Disaggregation or Decomposition-
 Breaking big stories into smaller stories
 Goal is to define stories that can fit into single iterations
 Planning Poker-
 It is a tool to facilitate group sizing
 What do you need?
 Entire team – including product owner/customer
 Deck of planning poker cards with point sizes
 Stories
Estimating in Teams: Planning Poker
 Poker ‘Cards’ for Each ‘Player’
 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, Infinity (Fibonacci-like sequence)
 Product Owner Reads a User Story or Describes a Feature

 Each player, At The Same Time, shows their Estimate Card
 Team Iterates and Discusses Until Consensus Reached
 Facilitator Records the Story Point Value

 Encourages Discussion, But Prevents Endless Discussion
 Particularly Useful for Size Estimating for Release Planning

 Less Frequently Used for Estimating Tasks in Sprint Planning

Velocity
 How many Story Points or Ideal Days of Work can a Team Actually Get ‘DONE’ in a Real
Sprint for COMPLETED user stories?
 Track the Highest, Average and Lowest over a Time Period
 Used to plan Sprints, Releases and to forecast the Progress
 Not Comparable Across Teams – Teams Develop Their Own Signature/velocity
 Velocity will typically fluctuate within a reasonable range, which is perfectly fine. If velocity
fluctuates widely for more than one or two iterations, the team may need to re-estimate
and/or renegotiate the release plan.
 Team velocity will typically stabilize between 3 and 6 iterations.
 Future iterations use the proven history of the team to determine how much the team can
do. Therefore, velocity is the right measure to use for planning future iterations.
 Velocity's value comes from its inherent consistency. A fixed iteration length helps drive the
reliable rhythm of a project.

Talking Point
 Question:
During a Sprint, a Development Team determines that it will not be able to finish the
complete forecast. Who should be present to review and adjust the Sprint work selected?
A) The Scrum Master, the project manager and the Development Team.
B) The Product Owner and the Development Team.
C) The Product Owner and all stakeholders.
D) The Development Team.

Answer and Feedback
 Correct Answer:
B) The Product Owner and the Development Team.
 Feedback:
During the Sprint, scope may be clarified and re-negotiated between the Product Owner
and Development Team as more is learned.

Events/Ceremonies in Scrum

Events in Scrum

Daily Scrum Meeting aka Daily Stand Up
 15-minute time-boxed daily event  Anyone can attend as an ‘observers’ but cannot ‘participate’
 Same place and time each day. during the Daily Standup event.
 Developers inspects sprint progress and adapts new actions  Observers can discuss points offline with Scrum Master, who
to achieve the Sprint Goal. will convey the same to rest of Scrum Team at an appropriate
event.
I have completed
Task 1 and Task 2
since last Stand
Up meeting? Business Users,
Stakeholders,
Auditors, etc.. Scrum Master
Non-participants
I plan to resume
Task 2 and pick
up Task 3 too.
Developers
Anything else My impediments /

relevant to blockers are: xxx Distinguished
current Sprint!! yyy zzz Personalities
Product Owner
(CEO, CTO, etc.)
Development Team - Only developers participate in the Scrum Master and Product Owner may ‘observe’ the stand up
Daily Stand up/daily scrum calls and discuss how the even but do NOT ‘participate’.
Sprint Goal can be achieved. Scrum Master facilitates by Product Owner - Queries with PO can be taken up individually by
ensuring that all the developers participates in the stand up respective developers.
and no one else speaks during the event. Others can Scrum Master - can help with solutions, but not a mandate to
‘observe’
Copyright but NOT
© 2019 Tech ‘participate’.
Mahindra. All rights reserved.
help with solutions on every problems faced by the Developers. 55
Scrum of Scrum
 To deliver a complex, multi-platform, cross-team dependent product, daily
Scrum of Scrums calls are organized
 Purpose is to coordinate activities and address integration issues
 A representative of the Scrum Team would usually participate on behalf of
entire Scrum Team and contributes to progress of the larger agenda
 Relevant topics are discussed. Following are the sample questions:
– What did my sprint team do yesterday to advance the objectives of the Sprint
– What will my sprint team do today
– What are the barriers that could keep my team from meeting its commitment to the Sprint
 This meeting takes place after daily SCRUM of the teams

Example BVC of Stories
Big Visible Charts (BVC)

Definition of DONE (DoD)
Manager – Is the feature you were working on “done”?
Developer - “Yes” ..I checked in the code and had unit tested it…so its
“done” from my side.
Manager - Great, then we will go ahead and deploy it into the UAT
environment
Developer- But it has not been fully tested by QA, and still need to pass
a code review
Manager- Well…….that means its not DONE…..
Root Cause of above “very common ” scenario in Scrum is

– there is no common, clear, discussed, agreed upon
definition of “Done” for a sprint within the scrum team.

Definition of DONE (DoD)
Definition of done (DoD) captures activities, that should be

realistic and committed by the team for completion at each
level (feature, sprint, release)
 DoD is a checklist activities agreed among the Development

Teams required to produce a potentially releasable
software/increment at the end of each sprint
 Ideally, potentially shippable increment is equivalent to the

Definition of Done
 DoD is the primary reporting mechanism for team members.
 The DoD is used to validate whether all agreed tasks are

accounted for
 Different DoD at various levels:

 DoD for a feature (story or product backlog item)
 DoD for a sprint (collection of features developed within a
sprint)
 DoD for a release (potentially shippable state)

Examples of DoD

Sprint Review
 A Sprint Review is held at the end of the Sprint to inspect the Increment and
adapt the Product Backlog if needed
 During the Sprint Review, the Scrum Team and stakeholders collaborate about
what was done in the Sprint
 Time boxed – 4 hours in one month
 Informality is encouraged for open discussion
 The Sprint Review includes the following elements:
– Attendees include the Scrum Team and key stakeholders invited by the Product Owner
– The Product Owner explains what Product Backlog items have been “Done” and what has not
been “Done”
– The Development Team discusses what went well during the Sprint, what problems it ran into,
and how those problems were solved

Sprint Review
– The Development Team demonstrates the work that it has “Done” and answers questions about
the Increment
– The Product Owner discusses the Product Backlog as it stands. He or she projects likely target
and delivery dates based on progress to date (if needed)
– The entire group collaborates on what to do next, so that the Sprint Review provides valuable
input to subsequent Sprint Planning
– Review of how the marketplace or potential use of the product might have changed what is the
most valuable thing to do next; and,
– Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated
releases of functionality or capability of the product.

Sprint Retrospective
 The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself
and create a plan for improvements to be enacted during the next Sprint.
 The Sprint Retrospective occurs after the Sprint Review and prior to the next
Sprint Planning.
 The Scrum Master participates as a peer team member in the meeting from
the accountability over the Scrum process.
 Time boxed – 3 hours in one month
 The purpose of the Sprint Retrospective is to:
– Inspect how the last Sprint went with regards to people, relationships, process, and
tools
– Identify and order the major items that went well and potential improvements; and,
– Create a plan for implementing improvements to the way the Scrum Team does its
work.

Sprint Retrospective
 The Scrum Master encourages the Scrum Team to improve, within the Scrum
process framework, its development process and practices to make it more
effective and enjoyable for the next Sprint.
 By the end of the Sprint Retrospective, the Scrum Team should have identified
improvements that it will implement in the next Sprint.

Release Planning
 Typically every 3 months – A goal and a plan for next release
 Stories are allocated to Sprints, based on all relevant factors e.g.:
 Business Values  Customer
 Size  Team
 Risk  Team / Customer
 Dependencies  Team
 Constraints  Team / Customer
 Release Plan is reflected in Product Backlog
 Updated continuously – At end of every Sprint at least
 Sample Release Plan

Release Planning based on Team Velocity
 Based on the organisations’ average velocity (baseline org velocity), a realistic
release schedule is chalked out – open to future changes
 Business wish list/priorities are listed and tagged against each
 Leave Hardening Sprint Empty Initially
 Do Not Plan to Exceed Team Velocity
– Use Previous Team Velocity, if known
OR
– if Team Velocity is Unknown, Estimate it by Calculating and Extrapolating
Assumed Velocity from a Few Stories
OR
– Using Commitment-Based Planning of a Full Sprint

Burn down Chart
 One of the mechanisms to track ‘what remains to be completed’ in the sprint
 Can be used for Projection
Please refer Iteration backlog and Burn down Chart on BMS

Burn down Chart
 Each task contains the amount of work remaining
 These values are updated continuously
 Plot the amount of work remaining across time
 Even though you might think that work remaining should always go down, new
work is always being discovered as the project is being built
 Expect the work remaining to go up and down.
 Since the team will be aiming to hit the number zero, the Burn Down chart is
emotionally powerful
 We get exciting about completing our work and seeing the chart tend toward
zero

Talking Point
 Question:
Why is the Daily Scrum held at the same time and same place?
A) The place can be named.
B) The consistency reduces complexity.
C) The Product Owner demands it.
D) Rooms are hard to book and this lets it be booked in advance.

Answer and Feedback
 Correct Answer:
B) The consistency reduces complexity.
 Feedback:
The Daily Scrum is held at the same time and place each day to reduce complexity.

Talking Point
 Question:
The CEO asks the Development Team to add a "very important" item to a Sprint that is in
progress. What should the Development Team do?
A) Add the item to the current Sprint without any adjustments.
B) Add the item to the current Sprint and drop an item of equal size.
C) Add the item to the next Sprint.
D) Inform the Product Owner so he/she can work with the CEO.

Answer and Feedback
 Correct Answer:
D) Inform the Product Owner so he/she can work with the CEO.
 Feedback:
The items selected for a Sprint have been selected as most valuable with the Product
Owner. The items serve the Sprint's goal. No changes should be made that endanger the
Sprint Goal. No one external to the Scrum Team can force changes on the Development
Team (Sprint Backlog) and the Product Owner (Product Backlog).

Talking Point
 Question:
An organization has decided to adopt Scrum, but management wants to change the
terminology to fit with terminology already used. What will likely happen if this is done?
A) Without a new vocabulary as a reminder of the change, very little change may actually
happen.
B) The organization may not understand what has changed with Scrum and the benefits
of Scrum may be lost.
C) Management may feel less anxious.
D) All answers apply

Answer and Feedback
 Correct Answer:
D) All answers apply

Talking Point
 Question:
When does the next Sprint begin?
A) Next Monday.
B) Immediately following the next Sprint Planning.
C) When the Product Owner is ready.
D) Immediately after the conclusion of the previous Sprint.

Answer and Feedback
 Correct Answer:
D) Immediately after the conclusion of the previous Sprint.
 Feedback:
A new Sprint starts immediately after the conclusion of the previous Sprint.

Implementation @ Tech Mahindra

Agile Implementation
Days
-15 T0 30 60 90 180
Release 1
Release 2
Planning
Planning
Hot
House
•Prioritised Business
Scenarios/User Stories
•Business Delivery Plan Release 2 (90 days)
Release 1 (90 days)
Iteration
Iteration
Iteration
Iteration
Iteration
Iteration
Iteration
Iteration
Iteration
Iteration
Iteration
Iteration
Iteration
Iteration
Iteration
Iteration
Iteration
Iteration
0 DAY 10
1 2 3 4 5 6 7 8 9 10
Sprint or
Iteration Sprint
Planning planning
Retro-
spective

Agile Methodology
 Scrum as project development methodology
 Some of the XP practices can be adopted
 Highlights
– 90 day release cycle
– 2 week sprint (iteration) (can be tailored)
– Pre-90 days
– Hot housing
 Release
– Iteration 0
– Iteration 1 to (n-1)
– Iteration n

Pre – 90 days
Objective – To finalize product vision
Nothing to start Process Owner – Delivery Manager
Inputs with
Conduct Hot Define high level Define Minimum

Tasks House requirements E2E solution design
QG 1
Tech Hot Housing

Mahindra
Guidelines
Process
Outputs High level High level design or

Requirements solution architecture
document
Quality Gates Approval of high level requirements & design from customer
QG 1

Iteration 0 Process Owner – Scrum Master
Objective – To plan for release

High level High level design or
Inputs requirements solution architecture
Development
Release Mobilize resources
and Testing
and and infrastructure
Environ setup
Tasks Project
Planning
Detail out user stories Enhance Establish
QG 2 or use cases for next design coding
iteration document standards
Tech Project plan SCRUM Use case User Release

Mahindra template for Agile guidelines template story management
Process document template process
Project Plan Release Enhanced User stories for Coding

Outputs Plan/Product design next iteration standards
backlog
Quality Gates Approval of Project plan and Release plan (product backlog)
QG 2

Iteration 1- (n-1) Process Owner – SCRUM Master
Objective – Plan and monitor sprint/iteration

Release Plan/ User stories or use Enhanced design
Inputs Product backlog cases for iteration document
Explain Develop and test Continuous Integration

Sprint/ user stories user stories building testing
Tasks Iteration Project Update
planning Scrum Plan for next Show and tell
Monitoring & product
meetings sprint/ Retrospective
progress backlog
iteration
reporting
QG 3
Tech Product Sprint burn Iteration Scrum Template for

Mahindra & Sprint down metric guidelines Retrospective
Process backlog template sheet
template
Outputs Project burn Tested User stories Enhanced Updated Action points
down chart product for next Design Iteration from
increment iteration Metric Retrospective
Quality Gates Project burn down chart, Iteration metric sheet updated for iteration data
QG 3
Code walkthrough, Test logs

Iteration n - The stabilization sprint
 Prepares the developed product for final release
 Update final documentation
 Pre-release testing
 Regression testing
 System/Integration testing
 Retrospectives
 Prepare for the next release

Agile Development Practices @ TechM
Structured Agile Development Practices @ TechM
Processes
SCRUM XP
Requirement Customer Collaboration

Analysis
Hot Housing / Story Definition
System and Release Planning

Software
Design
Use Cases / Architecture Definition
UML based modeling

Coding
and Unit Iterative development
Testing
Retrospectives Continuous Integration
Daily Stand Ups Re-factoring

Integration
and System
Testing
Planning Game
Small releases
Coding standards
Operations &
Maintenance Pair-Programming
Project Management
Risk Management
Change Management
Processes for each iteration / phase Governance models
Issues Management
Communication Model
Collaboration Tools

Agile Metrics at TechM
S. No PARAMETERS
S. No PARAMETERS
1 On Time Delivery? 21 % Change in velocity
2 Effort Variance (EV)% 22 Review Efficiency (%)
23 Test Efficiency (%)
3 Schedule Variance
4 Dev Productivity (USP/UCP/FP per PM)
5 Dev Productivity (Hrs per USP/UCP/FP)
6 Baselined Productivity (USP/FP/UCP per PM) Metrics report template
7 Overall Productivity (USP/FP/UCP per PM) for agile Development
8 Wtd. Defect Density and Enhancements is
9 Non Wtd. Defect Density available in BMS.
10 Wtd. DRE (CST)%
11 Non Wtd. DRE (CST)%
12 Wtd. DRE (CIT)%
13 Non Wtd. DRE (CIT)%
14 Wtd DRE (SIT/NBT)%
15 Non Wtd DRE (SIT/NBT)%
16 Wtd. DRE (E2E Testing)%
17 Non Wtd. DRE (E2E Testing)%
18 Wtd. Field Defect Density
19 Non Wtd. Field Defect Density
20 Velocity variance

Agile PPB at TechM
Based on the Metrics reports provided by projects, Metrics council will analyze the reports
at Org level and Process performance Baselines (PPB) are published once in six months.
The PPBs are available in BMS.
PPB Link

Key Agile Artifacts in BMS
Sr # Artifact
1Agile Kit for PM
2Agile Estimation Procedure
3Product Backlog Template
4User Story Template
5Sprint Backlog Template
6Scrum Guidelines
7Agile Guidelines
Recommended Books
 Agile Software Development with Scrum
 Ken Schwaber and Mike Beedle
 Agile Project Management with Scrum

 Ken Schwaber and Mike Beedle
 User Stories Applied

 Mike Cohn
 Lean Software Development

 Mary Poppendieck

Recommended Websites
 Most authentic sites on Scrum are:
– www.scrumalliance.org
– www.scrum.org
 Additional information:
– www.scaledagileframework.com
– One can google web and be able to identify appropriate implementation
examples and reading material available on world wide web.

Thank you
Visit us at www.techmahindra.com
Disclaimer
Tech Mahindra Limited, herein referred to as TechM provide a wide array of presentations and reports, with the contributions of
various professionals. These presentations and reports are for informational purposes and private circulation only and do not
constitute an offer to buy or sell any securities mentioned therein. They do not purport to be a complete description of the markets
conditions or developments referred to in the material. While utmost care has been taken in preparing the above, we claim no
responsibility for their accuracy. We shall not be liable for any direct or indirect losses arising from the use thereof and the viewers are
requested to use the information contained herein at their own risk. These presentations and reports should not be reproduced, re-
circulated, published in any media, website or otherwise, in any form or manner, in part or as a whole, without the express consent in
writing of TechM or its subsidiaries. Any unauthorized use, disclosure or public dissemination of information contained herein is
prohibited. Unless specifically noted, TechM is not responsible for the content of these presentations and/or the opinions of the
presenters. Individual situations and local practices and standards may vary, so viewers and others utilizing information contained
within a presentation are free to adopt differing standards and approaches as they see fit. You may not repackage or sell the
presentation. Products and names mentioned in materials or presentations are the property of their respective owners and the
mention of them does not constitute an endorsement by TechM. Information contained in a presentation hosted or promoted by
TechM is provided “as is” without warranty of any kind, either expressed or implied, including any warranty of merchantability or
fitness for a particular purpose. TechM assumes no liability or responsibility for the contents of a presentation or the opinions
expressed by the presenters. All expressions of opinion are subject to change without notice.

Agile Training Ver 2.4

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Agile Training Ver 2.4

Загружено:

Авторское право:

Доступные форматы

Agile Methodology Training

Copyright © 2019 Tech Mahindra. All rights reserved. 1

– Agile vs. Traditional Approach

– Agile methods - Scrum, XP, DSDM, RUP

– Scrum Roles and Responsibilities

 Implementation of Agile @ Tech Mahindra

Development • Coding, Unit Testing

Testing • Testing, Integration Testing

Copyright © 2019 Tech Mahindra. All rights reserved. 3

Copyright © 2019 Tech Mahindra. All rights reserved. 4

Copyright © 2019 Tech Mahindra. All rights reserved. 5

Agility is the ability to both create and respond to change in

Copyright © 2019 Tech Mahindra. All rights reserved. 6

 They all emphasized

Individuals and Interactions over Processes and Tools

Working Software over Comprehensive Documentation

Customer Collaboration over Contract Negotiation

Responding to Change over Following a Plan

Copyright © 2019 Tech Mahindra. All rights reserved. 8

Copyright © 2019 Tech Mahindra. All rights reserved. 9

Copyright © 2019 Tech Mahindra. All rights reserved. 10

 Time and Cost is variable  Focus on Quality and Value

Copyright © 2019 Tech Mahindra. All rights reserved. 11

Copyright © 2019 Tech Mahindra. All rights reserved. 12

Copyright © 2019 Tech Mahindra. All rights reserved. 13

Copyright © 2019 Tech Mahindra. All rights reserved. 14

Extreme Programming (XP) - Refactoring – the ongoing redesign of the

Dynamic Systems Development

Copyright © 2019 Tech Mahindra. All rights reserved. 15

Copyright © 2019 Tech Mahindra. All rights reserved. 16

Copyright © 2019 Tech Mahindra. All rights reserved. 17

In IT context, it is Project Management Methodology for Agile development.

Copyright © 2019 Tech Mahindra. All rights reserved. 18

Scrum in Action - Planning through Software Delivery

Scrum Foundation The process must be visible to

Scrum users must

Empiricism adjusted. An adjustment must

Copyright © 2019 Tech Mahindra. All rights reserved. 20

Copyright © 2019 Tech Mahindra. All rights reserved. 21

Copyright © 2019 Tech Mahindra. All rights reserved. 22

Copyright © 2019 Tech Mahindra. All rights reserved. 23

Copyright © 2019 Tech Mahindra. All rights reserved. 24

Copyright © 2019 Tech Mahindra. All rights reserved. 25

Copyright © 2019 Tech Mahindra. All rights reserved. 26

Product Owner Development Team Organization

Copyright © 2019 Tech Mahindra. All rights reserved. 27

Copyright © 2019 Tech Mahindra. All rights reserved. 28

– Must attend Daily Scrum

Copyright © 2019 Tech Mahindra. All rights reserved. 30

Copyright © 2019 Tech Mahindra. All rights reserved. 31

 The Product Owner - based on the

 A queue of Work Items for Scrum Team

 Release Planning includes selection of

REQ N  Owned and ordered/prioritized by

Copyright © 2019 Tech Mahindra. All rights reserved. 33

Copyright © 2019 Tech Mahindra. All rights reserved. 34

Product Increment(s) via  Visible all the work for transparency

 Includes at least one high priority

Copyright © 2019 Tech Mahindra. All rights reserved. 36

Epic – a set of logically grouped user stories/functionalities

Copyright © 2019 Tech Mahindra. All rights reserved. 38

Copyright © 2019 Tech Mahindra. All rights reserved. 39

Shorter Release Cycles = Shorter Sprints