Professional Documents
Culture Documents
Gurunath Vellanki
GURUNATH VELLANKI
About Me
SENIOR IT CONSULTANT, AGILE
Conducted 100+ sessions on Agile, 30+ sessions on TDD/BDD. Conducted trainings to Senior VP’s to
COACH AND CORPORATE TRAINER
freshers with high feedback ratings. Expert in Customized Trainings.
(INDIA AND OVERSEAS)
Experience
Certified Scrum Professional
• Certified Scrum Master Management * Leadership & Mentoring * Customized
• SAFe Agilist Trainings in India and Abroad and Consulting /Coach in
• ITIL Foundation Delivery/Agile.
• Six Sigma GB • Worked on major verticals like Telecom, Finance and
• Lean thinking Insurance Sector, Banking, Manufacturing, Government
• PRINCE2® Practitioner • Experience in Greenfield, Product development projects
Training
Role
Gurunath Vellanki
• Member of many Agile Forums. Regularly attends the various agile gatherings and upgrades the training / coaching techniques
GURUNATH VELLANKI
AGILE
It is a philosophy that uses organization model based on
People
Collaboration
Values
When applied, produces on Empirical Process
GURUNATH VELLANKI
BEGIN AGILE
GURUNATH VELLANKI
EMPIRICAL PROCESS
GURUNATH VELLANKI
AGILE MANIFESTO
GURUNATH VELLANKI
Agile principles
1. Customer satisfaction by early and continuous delivery of valuable
software
2. Welcome changing requirements, even in late development
3. Working software is delivered frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be
trusted
6. Face-to-face conversation is the best form of communication (co-
location)
7. Working software is the principal measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10. Simplicity—the art of maximizing the amount of work not done—is
essential
11. Self-organizing teams
12. Regular adaptation to changing circumstance
GURUNATH VELLANKI
Traditional Method VS Agile
GURUNATH VELLANKI
Traditional Method VS Agile
⚫Requirements for the whole project vs. requirements for the
iteration, overview of the bigger picture
⚫Clearly defined roles vs Cross-functional teams
⚫Long time estimation vs short time estimation
⚫Long-time budgeting vs short time budgeting
⚫Abandoning project in the middle leaves useless artefacts vs
each iteration delivers business value
⚫Extensive out-of-synch documentation vs lean general and in-
line code documentation
⚫Changes are expensive vs changes are expected and cheap
⚫Long feedback loop between customer and developer vs almost
immediate feedback
GURUNATH VELLANKI
Sequential vs. Overlapping Dev.
GURUNATH VELLANKI
Agile Pros and Cons
Pros:
More Flexibility Compared to Waterfall Methodology.
Iterations Provide Immediate Feedback.
Fewer Defects in the Final Product.
Cons:
Immediate Feedback Could Result to Scope Creep
Documentation Gets Left Behind.
GURUNATH VELLANKI
TOP 10 REASONS AGILE PROJECTS FAIL
GURUNATH VELLANKI
Agile Documentation
Essential: Document with just barely good enough detail.
Valuable: Document only when we actually need it, not when we want it.
Timely: Documentation should be done in a just-in-time (JIT) manner,
when we need it.
Documentation becomes part of the development process, not a separate
activity. Since the documentation is actually useful, the whole team has an
interest in maintaining it
Documentation should take on a collaborative nature. It should not be
written by one person to perfection, and then shared with others. It
should instead be shared often during draft to gain input.
Focus on just barely good enough documentation and avoid big upfront
details which typically means a lot of guessing and wasted time. Barely
good enough means document what you currently know.
Documentation can take many forms. It is not only a Word document,
documentation can live on a wiki, in the Agile planning tool, as
comments in code, and much more
GURUNATH VELLANKI
Agile Development Methods
Agile methods:
Scrum
Extreme Programming
Adaptive Software Development (ASD)
Dynamic System Development Method
(DSDM)
GURUNATH VELLANKI
Extreme Programming
GURUNATH VELLANKI
Adaptive Software Development (ASD)
The characteristics of an ASD life cycle are that it is mission
focused, feature based, iterative, timeboxed, risk driven, and change
tolerant.
The focus of adaptive software development is in the computer
code. Instead of planning the software out before hand, developers
have a basic idea in their heads and they go to work. When pieces
need changing or adapting to a new system, the coders simply do it.
If the program needs a patch, somebody just makes it.
Overall, the lack of pre-planning steps allows the developers to
make the software very quickly. While this will occasionally result in
software that doesn’t perform the precise functions required, that is
generally not a problem. The developmental cycle in this process is
so short that a new version with additional features can come out
very quickly. This process of rapid prototyping is the cornerstone of
both adaptive software development and rapid application
development.
GURUNATH VELLANKI
Dynamic System Development Method (DSDM)
GURUNATH VELLANKI
Software development lifecycle support in agile methods
⚫ KEY: Project management
⚫ Process
⚫ Practices / activities / work products
⚫Agile
RUP
⚫Crystal
⚫DSDM
⚫XP
⚫FDD
⚫Scrum
⚫Concept ⚫Requirements ⚫Design ⚫Code ⚫Unit test ⚫Integration ⚫System ⚫Acceptance ⚫System
Creation Specification test test test in use
GURUNATH VELLANKI
Agile Microsoft Solutions Framework
Foundational Principles
Foster open communications
Work toward a shared vision
Empower team members
Establish clear accountability and shared responsibility
Focus on delivering business value
Stay agile, expect change
Invest in quality
Learn from all experiences
GURUNATH VELLANKI
Agile UP
Phases
Inception, Elaboration, Construction, Transition
Disciplines
Model, Implementation, Test, Deployment, Configuration
Management, Project Management, Environment
Philosophies
Your staff knows what they're doing, Simplicity, Agility, Focus
on high-value activities, Tool independence, You'll want to
tailor the AUP to meet your own needs
GURUNATH VELLANKI
Crystal Clear
Frequent Delivery of Usable Code to Users
(required)
Reflective Improvement (required)
Osmotic Communication Preferably by Being Co-
Located (required)
Personal Safety
Focus
Easy Access to Expert Users
Automated Tests, Configuration Management, and
Frequent Integration
GURUNATH VELLANKI
DSDM
Principles
User involvement is the main key, The project team must be
empowered, Frequent delivery of products, Delivering a
system that addresses the current business needs,
Development is iterative and incremental, Changes are
reversible, High level scope and requirements should be base-
lined, Testing is carried out throughout the project life-cycle,
Communication and cooperation among all project
stakeholders
Techniques
Timeboxing, MoSCoW, Prototyping, Testing, Workshop,
Modelling
GURUNATH VELLANKI
eXtreme Programming (XP)
Values
Communication, Simplicity, Feedback, Courage, Respect
Activities
Coding, Testing, Listening, Designing
Practices
Pair programming, Planning Game, Test Driven
Development, Whole team, Continuous Integration, Design
Improvement, Small Releases, Coding Standards, Collective
Code Ownership, Simple Design, System Metaphor,
Sustainable Pace
GURUNATH VELLANKI
Feature Driven Development
Activities
Develop Overall Model, Build Feature List, Plan By Feature,
Design By Feature, Build By Feature, Milestones
Best practices
Domain Object Modeling
Developing by Feature
Individual Class (Code) Ownership
Feature Teams
Inspections
Configuration Management
Regular Builds
Visibility of progress and results
GURUNATH VELLANKI
Scrum
Techniques
Team creation
Backlog creation
Project segmentation
Scrum meetings
Burndown charts
Phases
Review release plans
Distribution, review and adjustment of product standards
Sprint
Sprint review
Closure
GURUNATH VELLANKI
Key Terms and Examples (1)
Agile Method Term Examples
Agile Microsoft Principles Foster open communications, empower team members, establish
Solutions clear accountability and shared responsibility
Framework
Mindsets Focus on Business Value, Foster a Team of Peers, Internalize
Qualities of Service
Agile UP Phases Inception, elaboration, construction, transition
Disciplines Model, implementation, test, project management
Philosophies Simplicity, tool independence
Crystal Clear Properties Frequent delivery of usable code, reflective improvement,
osmotic communication
Strategies Incremental Rearchitecture, Information Radiators.
Techniques Daily Stand-up Meetings, Side-by-Side Programming, Burn
Charts.
DSDM Principles User involvement, empowered project team must, frequent
delivery of products, testing throughout the project life-cycle
Techniques Timeboxing, MoSCoW, testing, workshop
GURUNATH VELLANKI
MoSCoW
MoSCoW is a useful technique used in management, business analysis and
software development to reach a common understanding with stakeholders on the
importance they place on the delivery of each requirement -
also known as MoSCoW prioritization or MoSCoW analysis.
GURUNATH VELLANKI
Techniques Stressed in Methods
Agile AUP Crystal DSDM XP FDD Scrum
MSF Clear
Active stakeholder
participation
Agile Model Driven
Development (AMDD)
Code refactoring
Code regression testing
Co-location
Common coding guidelines
Continuous integration
Pair programming
Single sourcing information
Test Driven Design (TDD)
⚫These techniques
explicitly excluded
GURUNATH VELLANKI
Scrum in 100 words
Scrum is an iterative incremental process of software
development commonly used with agile software
development
Scrum is an agile process that allows us to focus on
delivering the highest business value in the shortest
time.
It allows us to rapidly and repeatedly inspect actual
working software (every two weeks to one month).
The business sets the priorities. Our teams self-manage to
determine the best way to deliver the highest priority
features.
Every two weeks to a month anyone can see real working
software and decide to release it as is or continue to
enhance for another iteration.
GURUNATH VELLANKI
History of Scrum
1995:
Design of a new method: Scrum by Jeff Sutherland & Ken
Schwaber
Enhancement of Scrum by Mike Beedle & combination of Scrum
with Extreme Programming
1996:
introduction of Scrum at OOPSLA (Object-Oriented
Programming, Systems, Languages & Applications)
conference
2001:
publication “Agile Software Development with Scrum” by
Ken Schwaber & Mike Beedle
GURUNATH VELLANKI
Characteristics
Self-organizing teams
Product progresses in a series of month-long “sprints”
Requirements are captured as items in a list of
“product backlog”
No specific engineering practices prescribed
Uses generative rules to create an agile environment
for delivering projects
One of the “agile processes”
GURUNATH VELLANKI
TIMEBOX
Fixed span of time called as Sprint in Scrum and has
- Fixed Goal
- Fixed Team
- Fixed Length
- Product Increment at the end
Maximum Length of the Sprint recommended by Scrum frame
work is 4 weeks
Why TIMEBOXING
1. Helps stay focused on the Goal
- By eliminating procrastination
- By Providing frequent opportunity to get customer
feedback
2. Improve Predictability
- Measure and learn to deliver at a sustainable pace
- Inspect and Adopt process and plan
GURUNATH VELLANKI
DEFINITION OF READY
Examples
- No open questions about PBI
- Acceptance Criteria written
- No technical dependencies
- PBI estimated & split small enough to fit into a Sprint
- INVESTED
GURUNATH VELLANKI
DEFINITION OF DONE
It is an exit criteria agreed by Product Owner and
development Team to consider a PBI done and ready to
be shipped.
Examples
- Coded - Test cases written
- Reviewed - Tested
- Bugs fixed - Integrated
- Packaged - Test cases automated
- Deployed - Accepted by Product Owner
GURUNATH VELLANKI
SCRUM FRAMEWORK
An Empirical way of solving complex problems and consists of
Roles – 3
Product Owner
Development Team
Scrum Master
Artefacts – 3
Product Backlog
Sprint Backlog
Product Increment
Ceremonies – 5
Sprint Planning
Daily Scrum
Product Backlog Refinement
Sprint Review
Sprint Retrospective
Agreement – 2
Definition of Ready
Definition of Done
GURUNATH VELLANKI
How Scrum Works?
GURUNATH VELLANKI
Scrum Process
GURUNATH VELLANKI
Scrum Values
Scrum has five values Commitment Focus
Be willing to commit to Do your job. Focus all
Commitment a goal. Scrum provides your efforts and skills
the tools for it. on doing the work that
Focus you’ve committed to
doing. Don’t worry
about anything else.
Openness
Openness
Respect Scrum keeps
everything about a
Courage project visible to
Respect
everyone.
WARNING: If your team Individuals are shaped
by their background
lacks these values, you will Courage
and their experiences.
It is important to
most probably fail in scrum Have the courage to
respect the different
people who comprise a
commit, to act, to be team.
implementation open and to expect
respect.
GURUNATH VELLANKI
PRODUCT OWNER
Represents the business side of the Product Development
Focus
Maximize the Value of the work done by the Scrum Team to
achieve the Product Vision
Responsible for
Product Vision
Requirements
Stakeholder Management
Scope Management
Cost Management
Release Management
GURUNATH VELLANKI
DEVELOPMENT TEAM
Focus
Develop high quality solution to fulfil the Product
Vision
Responsible for
Delivering Incremental Solution
Quality of the solution
Technical Practices
GURUNATH VELLANKI
SCRUM MASTER
Focus
Coach the Scrum Team to collaborate and maximize
their potential to achieve Product Vision
Responsible for
Scrum Team’s Focus on the goal
Culture of purpose
Collaborative organization structure
Collaborative practices and process
GURUNATH VELLANKI
PRODUCT INCREMENT
GURUNATH VELLANKI
PRODUCT BACKLOG
Anything and everything required to fulfil the Product Vision
Contains
Functional requirements
Non-functional requirements
Change requests
Enhancements
Defects
POC/Spike
GURUNATH VELLANKI
PRODUCT BACKLOG Is
Detailed enough
Emergent
Estimated
Prioritized
Expressed as
User story
Usecase
Flowchart
Voice of Customer
Etc.
GURUNATH VELLANKI
PRODUCT BACKLOG REFINEMENT
Purpose:
For Scrum Team to refine and keep the
Product Backlog ready for future Sprints
Participants:
Scrum Team
Other SME’s
Representatives from downstream or upstream
products
GURUNATH VELLANKI
PRODUCT BACKLOG REFINEMENT
Inputs
Product Backlog
Product Vision
Comments from Sprint Review
Outputs:
Refined Product Backlog
(Ready for at least 2 sprints)
GURUNATH VELLANKI
PRODUCT BACKLOG
REFINEMENT
Activities
1. Understand
PO explains PBI’s to Team and Team asks questions
2. Refine
Scrum Team adds details such as workflow, infrastructure
requirement, dependencies, business rules, data etc.
3. Estimate and Split
Development team estimates PBI’s & split them until they
small enough for a Sprint
GURUNATH VELLANKI
VELOCITY
GURUNATH VELLANKI
Scrum Framework
Roles :
Product Owner
Scrum Master
Team
Ceremonies :
Sprint Planning
Daily Scrum Meeting
Sprint Review & Sprint Retrospective
Artifacts :
Product Backlog
Sprint Backlog
Burn down Chart
GURUNATH VELLANKI
Product Owner
Holds the vision for the product
Defines the features of the product
GURUNATH VELLANKI
The Business Analyst Role
The role of the business analyst is much the same on an Agile project as
it would be on a Waterfall project. The business analyst is still the point
person to help develop and manage requirements. In an Agile project,
business analyst’s role is to work with the product owner to help define
the priority of the backlog, pushing those items forward on the
schedule that will bring the customer the greatest value.
Product owners make decisions about what the backlog is and which
items should be developed first. This in turn helps the business analyst
know which requirements (user stories) to further detail out for that
iteration.
The business analyst’s focus should be on eliciting and analyzing user
stories, allowing for better prioritization of the product backlog.
Business analysts will increasingly understand that successful user
stories rely heavily on what they already know about requirements
management and development (RMD). The business analyst’s RMD
skills will be the foundation for successful Agile projects.
GURUNATH VELLANKI
Scrum Approach
GURUNATH VELLANKI
Scrum Master
Ensures that the process is followed
Ensures that the team is fully functional and productive
Removes impediments
Shields the team from external interferences
Enables close cooperation across all roles, teams, and
organizations
Hosts the daily scrum, iteration review and planning
meetings
Is not the focal point of these meetings however!
GURUNATH VELLANKI
Team
Cross-functional, 7 +/- 2 members
Has the right to do everything within the boundaries
of the project guidelines to reach the Sprint objectives
Organizes itself and its work
Provides estimates for releases and sprints
Updates sprint estimates on a daily basis
GURUNATH VELLANKI
The TEAM definition as per Scrum guide 2009
THE TEAM
Teams of developers turn Product Backlog into increments of
potentially shippable functionality every Sprint. Teams are also cross-
functional; Team members must have all of the skills necessary to
create an increment of work. Team members often have specialized
skills, such as programming, quality control, business analysis,
architecture, user interface design, or database design. However, the
skills that Team member share – that is, the skill of addressing a
requirement and turning it into a usable product – tend to be more
important than the ones that they do not. People who refuse to code
because they are architects or designers are not good fits for
Teams. Everyone chips in, even if that requires learning new skills
or remembering old ones. There are no titles on Teams, and there
are no exceptions to this rule. Teams do not contain sub-Teams
dedicated to particular domains like testing or business analysis, either.
GURUNATH VELLANKI
Ceremonies
Sprint Planning Meeting
Daily Scrum
Sprint Review Meeting
Sprint Retrospective Meeting
GURUNATH VELLANKI
Sprints
Scrum projects make progress in a series of “sprints”
Analogous to XP iterations
Target duration is one month
+/- a week or two
But, a constant duration leads to a better rhythm
Product is designed, coded, and tested during the sprint
NO outside influence can interfere with the Scrum team
during the Sprint
Each Sprint begins with the Daily Scrum Meeting
GURUNATH VELLANKI
SPRINT PLANNING
Purpose
For Scrum Team to craft a Sprint Goal and create a plan to
achieve it
Participants
Scrum Team/Development Team
Inputs
PBI, Velocity or Capacity, Product Icrement
Output
Sprint Goal, Sprint Bcklog, sprint burndown
GURUNATH VELLANKI
SPRINT PLANNING
1. Craft a Goal
Answer why are you running this sprint
2. Crete Plan
Identify PBI’s required to achieve the Sprint Goal and
commit based on Team’s Velocity
3. Define Metrics
How do you know you have achieved the Sprint Goal
GURUNATH VELLANKI
No changes during the sprint
Change
GURUNATH VELLANKI
Sprint Planning Meeting
Product Backlog
Team Capabilities
Sprint Goal
Sprint Planning
Business Conditions
Meeting Sprint Backlog
Technology
Current Product
GURUNATH VELLANKI
Parts of Sprint Planning Meeting
1st Part:
Updating Product Backlog
Determining the Sprint Goal.
Participants: Product Owner, Scrum Master,
Scrum Team
2nd Part:
Participants: Scrum Master, Scrum Team
Creating Sprint Backlog
GURUNATH VELLANKI
Daily Scrum
Parameters
Daily
15-minutes
Stand-up
Not for problem solving
Three questions:
1. What did you do yesterday
2.What will you do today?
3.What obstacles are in your way?
GURUNATH VELLANKI
Daily Scrum
Is NOT a problem solving session
Is NOT a way to collect information about
WHO is behind the schedule
Is a meeting in which team members make
commitments to each other and to the
Scrum Master
Is a good way for a Scrum Master to track the
progress of the Team
GURUNATH VELLANKI
Scrum FAQs
Why daily?
“How does a project get to be a year late?”
“One day at a time.”
Fred Brooks, The Mythical Man-Month.
GURUNATH VELLANKI
Sprint Retrospective Meeting
Scrum Team only
Feedback meeting
Three questions
Start
Stop
Continue
GURUNATH VELLANKI
Scrum Artifacts
Product Backlog
Sprint Backlog
Burn down Charts
GURUNATH VELLANKI
Product Backlog
A list of all desired work on the project
Usually a combination of
story-based work (“let user search and
replace”)
task-based work (“improve exception
handling”)
List is prioritized by the Product
Owner
Typically a Product Manager, Marketing,
Internal Customer, etc.
GURUNATH VELLANKI
Product Backlog
Requirements for a system, expressed as a
prioritized list of Backlog Items
Is managed and owned by a Product Owner
Spreadsheet (typically)
Usually is created during the Sprint Planning
Meeting
Can be changed and re-prioritized before each
Planning Meeting
GURUNATH VELLANKI
Product Backlog Sample
Priority Epic Sprint User Story Role User Story Name Story Details Acceptance Test Criteria
GURUNATH VELLANKI
From Sprint Goal to Sprint Backlog
A subset of Product Backlog Items, which define the
work for a Sprint
Scrum team takes the Sprint Goal and decides what tasks
are necessary
Team self-organizes around how they’ll meet the Sprint
Goal
Manager doesn’t assign tasks to individuals
Managers don’t make decisions for the team
Is created ONLY by Team members
Each Item has it’s own status
Should be updated every day
GURUNATH VELLANKI
Sprint Backlog
GURUNATH VELLANKI
Sprint Backlog during the Sprint
Changes
Team adds new tasks whenever they need to
in order to meet the Sprint Goal
Team can remove unnecessary tasks
But: Sprint Backlog can only be updated by
the team
Estimates are updated whenever there’s
new information
GURUNATH VELLANKI
Sample Sprint Backlog
GURUNATH VELLANKI
Sprint Burn down Chart
Depicts the total Sprint Backlog hours
remaining per day
Shows the estimated amount of time to
release
Ideally should burn down to zero to the
end of the Sprint
Actually is not a straight line
Can bump UP
GURUNATH VELLANKI
Remaining Effort in Hours
5/
3/
20
0
100
200
300
400
500
600
700
800
5/ 02
5/ 900
20
5/ 02
7/
20
752
5/ 02
9/
2
5/ 00
11 2
/2
5/ 00
13 2
762
/2
5/ 002
15
664
/2
5/ 002
17
/2
5/ 00
Progress
19 2
619
/2
GURUNATH VELLANKI
5/ 002
Date
21
/2
304
5/ 00
23 2
/2
5/ 002
25
/2
5/ 00
27 2
264
/2
5/ 002
29
180
/2
5/ 00
31 2
/2
Sprint Burn down Chart
00
2
104
20
Release Burn down Chart
Will the release be done on right time?
X-axis: sprints
Y-axis: amount of hours remaining
The estimated work remaining can also
burn up
GURUNATH VELLANKI
Product Burn down Chart
Is a “big picture” view of project’s progress (all the
releases)
GURUNATH VELLANKI
Sprint Zero
GURUNATH VELLANKI
Scrum Process
GURUNATH VELLANKI
Scalability of Scrum
"Scrum of Scrums" or what called "Meta-Scrum“
Frequency of meetings is based on the degree of
coupling between packets
Agenda:
What has your team done since we last met?
What will your team do before we meet again?
Is anything slowing your team down or getting in their
way?
Are you about to put something in another team’s
way?
GURUNATH VELLANKI
Scalability of Scrum
GURUNATH VELLANKI
User Story
User Story
A user story represents a small piece of business value that a team can deliver in an iteration. While
traditional requirements (like use cases) try to be as detailed as possible, a user story is defined
incrementally, in three stages:
⚫ The brief description of the need
⚫ The conversations that happen during backlog grooming and iteration planning to nail down the details
⚫ The tests that confirm the story's satisfactory completion
Well-formed stories will meet the criteria of Bill Wake's INVEST acronym:
Why use user stories?
⚫ Keep yourself expressing business value
⚫ Avoid introducing detail too early that would prevent design options and inappropriately lock
developers into one solution
⚫ Avoid the appearance of false completeness and clarity
⚫ Get to small enough chunks that invite negotiation and movement in the backlog
⚫ Leave the technical functions to the architect, developers, testers, etc.
Independent We want to be able to develop in any sequence.
Avoid too much detail; keep them flexible so the team can adjust how much of the
Negotiable
story to implement.
Valuable Users or customers get some value from the story.
Estimatable The team must be able to use them for planning.
Large stories are harder to estimate and plan. By the time of iteration planning, the
Small
story should be able to be designed, coded, and tested within the iteration.
Document acceptance criteria, or the definition of done for the story, which lead to
Testable
test cases
GURUNATH VELLANKI
How do I write user stories?
User Story
When you're getting started with stories, a template can help ensure that you don't inadvertently start
writing technical tasks:
As a <user type>, I want to <function> so that <benefit> .
Examples:
As a delivery team member, I want to know which tasks I own so that I can decide what to work on now.
As a developer, I want to know which of my stories have failing test cases so that I can fix the code.
As a product owner, I want to be able to drag-and-drop prioritize all the product backlog items, so that I
can easily adjust priorities based on changing needs.
What size should a user story be?
A story should be small enough to be coded and tested within an iteration- ideally just a few days. When a
story is too large, it is called an "epic". Backlog items tend to start as epics, when they are lower priority.
For release planning, epics should be broken down into smaller chunks, but not so small that you've moved
into detailed design.
How detailed should a user story be?
Too broad
"A team member can view iteration status."
Too detailed
"A team member can view a table of stories with rank, name, size, package, owner, and status."
"A team member can click a red button to expand the table to include detail, which lists all the tasks, with
rank, name, estimate, owner, status."
Just right
"A team member can view the iteration's stories and their status, with main fields."
"A team member can view the current burndown chart on the status page, and can click it for a larger view."
"A team member can view or hide the tasks under the stories."
"A team member can edit a task from the iteration status page."
GURUNATH VELLANKI
User Story
How detailed should a user story be?
Too broad
"A team member can view iteration status."
Too detailed
"A team member can view a table of stories with rank, name,
size, package, owner, and status."
"A team member can click a red button to expand the table to
include detail, which lists all the tasks, with rank, name,
estimate, owner, status."
Just right
"A team member can view the iteration's stories and their status,
with main fields."
"A team member can view the current burndown chart on the
status page, and can click it for a larger view."
"A team member can view or hide the tasks under the stories."
"A team member can edit a task from the iteration status page."
GURUNATH VELLANKI
Requirements Prioritization (RP)
By the Book (BABOK):
The importance of requirements may be based on their relative value,
risk, difficulty of implementation, or on other criteria. These priorities
are used to determine which requirements should be targets for further
analysis and to determine which requirements should be implemented
first.
GURUNATH VELLANKI
Activity – 2 minutes
Scenario:
• It is 2p.m. on a Saturday. You have 4 hours – you want to accomplish the
following (driving your spouse’s/friend’s car):
GURUNATH VELLANKI
BABOK: Basis for Prioritization
Business Value: This approach prioritizes requirements based on cost-benefit analysis of their
relative value to the organization. The most valuable requirements will be targeted for development
first. This approach is common when enhancing an existing solution that already meets specified
minimal requirements, or when delivering the solution incrementally.
Business or Technical Risk: This approach selects requirements that present the highest risk of
project failure. Those requirements are investigated and implemented first to ensure that if the
project fails it does so after as little expenditure as possible.
Implementation Difficulty: This approach selects requirements that are easiest to implement. This
approach is often selected during a pilot of a new development process or tools or when rolling out a
packaged solution, as it allows the project team to gain familiarity with those things while working on
lower-risk requirements.
Likelihood of Success: This approach focuses on the requirements that are likely to produce quick
and relatively certain successes. It is common when a project is controversial and early signs of
progress are needed to gain support for the initiative.
Regulatory or Policy Compliance: This approach prioritizes requirements that must be
implemented in order to meet regulatory or policy demands imposed on the organization, which may
take precedence over other stakeholder interests.
Relationship to Other Requirements: A requirement may not be high value in and of itself, but
may support other high-priority requirements and as such may be a candidate for early
implementation.
Stakeholder Agreement: This approach requires the stakeholders to reach a consensus on which
requirements are most useful or valuable. It is often used in combination with one or more of the
other approaches described above.
Urgency: This approach prioritizes requirements based on time sensitivity.
Page 92
GURUNATH VELLANKI
Inputs to RP
Business Case: The business case states the key goals and measures of
success for a project or organization, and priorities should be aligned
with those goals and objectives.
Business Need: Serves as an alternative to the business case if no
business case has been defined.
Requirements: Any requirement may be prioritized, at any point in its
lifecycle. Requirements prioritization requires that requirements have
been stated by stakeholders; however, the requirements may not have
been fully analyzed or in their final form.
Requirements Management Plan: Defines the process that will be
used to prioritize requirements.
Stakeholder List, Roles, and Responsibilities: The list of
stakeholders, annotated with their levels of authority and influence, is
used to determine which stakeholders need to participate in
prioritization.
Page 93
GURUNATH VELLANKI
Challenges
Challenges in facilitating a requirements prioritization session include:
Non-negotiable Demands: Stakeholders attempt to avoid difficult
choices, fail to recognize the necessity for making tradeoffs, or desire to
rank all requirements as high priority.
Unrealistic Tradeoffs: The solution development team may intentionally
or unintentionally try to influence the result of the prioritization process
by overestimating the difficulty or complexity of implementing certain
requirements.
Too Many Stakeholders: It is not uncommon that many business area
resources demand to be in attendance at RP workshops (or even RD
workshops). The larger groups can be harder to coordinate and individual
agendas may not align with overall business objectives or future state
processes.
Poor Preparation: The BA may face scheduling, participation, and tool /
approach challenges in the RP session without proper preparation of
facilities, tools to be used, a focused approach and agenda, pre-organized
RP inputs, and clear delineation of ground rules for participants.
GURUNATH VELLANKI
Tools and Techniques
Decision Analysis
Decision Flow
Decision Tree
Observations (Job Shadowing)
Weighted Scorecards
Prototypes
Risk Analysis
Surveys / Questionnaires
MoSCoW
Benchmarking
Time Boxing/Budgeting
Context Diagrams (swim-lanes
Voting & ERDs)
Delphi Technique Document Analysis
Brainstorming
Ranking and Categorization
Past Project Templates (i.e. RTM)
Page 95
GURUNATH VELLANKI
Agile Estimation Methods
Function Points
A function point is a unit of measurement to express the amount of business
functionality an information system provides to a user
Wideband Delphi
The Wideband Delphi estimation method is a consensus-based technique for
estimating effort. It derives from the Delphi method which was developed in the 1950-
1960s at the RAND Corporation as a forecasting tool
GURUNATH VELLANKI
Release Planning
Take your product or project objectives and break it/them down to major
features. Find out the indispensable options (primary features) under
each major feature that must be present for delivery. Then include the
additional features that would be nice to have (secondary features).
Now take this mix (product backlog) and, including the product owner
and delivery team, lay these features against the fixed time blocks (for
example, sprints or months or quarters) you're working with, and you
have completed a draft release plan. Review the releases and features
included and determine whether the resources are adequate and what
interdependencies exist, and adjust the feature layout as needed.
The advantages of a release plan:
It gives the team a common vision about what needs to be achieved, and when.
It guides the team to make decisions during detailed planning.
It helps prioritize the stories.
It resolves conflicts and guides the team(s) toward the right balance on trade-
offs.
GURUNATH VELLANKI
Release Planning
GURUNATH VELLANKI
Release plan for feature driven plan
GURUNATH VELLANKI
Release plan for feature driven plan
GURUNATH VELLANKI
Velocity
In Scrum, velocity is how much product backlog
effort a team can handle in one sprint.
Example: Product Backlog of 100 story points.
The team has burned 30 story points in three
sprints. The velocity is 10 story points per
sprint. (30/3 = 10)
At the current velocity this team would project it
would finish the remaining story points in 7
sprints.
GURUNATH VELLANKI
Two views of agile testing
eXtreme Testing Exploratory Testing
Manual testing by professional skilled
Automated unit testing testers
Developers write tests Freedom, flexibility and fun for testers
Test first development Controllability, reliability and high quality
Daily builds with unit tests for managers
always 100% pass Optimized to find bugs
Functional testing Continually adjusting plans, re-focusing
on the most promising risk areas
Customer-owned Following hunches
Comprehensive Minimizing time spent on documentation
Repeatable In exploratory testing, tests are designed and
Automatic executed at the same time, and they often are not
Timely recorded.
You build a mental model of the product while you
In scripted testing, tests are first designed and test it. This model includes what the product is and
recorded. Then they may be executed at some how it behaves, and how it’s supposed to behave.
later time or by a different tester
Focus on manual validation –
Focus on automated verification – making testing activities agile
enabling agile software
development
GURUNATH VELLANKI
Gurunath Vellanki
GURUNATH VELLANKI
What does a Scrum Master do all day?
For starters, we know the Scrum Master doesn’t plan
the release, because that’s done by the product owner
and the team. We know he doesn’t manage the
developers because the Scrum team is self-organizing;
and we know he’s not even the guy who’s accountable
if the end result sucks (that’s the product owner too).
GURUNATH VELLANKI
So what’s left?
If a product owner is like the head that makes decisions, and a Scrum team is like the body
that executes your plan, then the Scrum Master could be considered the ooey-gooey
insides that hold everything together.
More simply put, the Scrum Master takes on the administrative, coaching and leadership
roles that make Scrum development possible. That means he’ll usually spend his days:
Facilitating (not participating in) the daily standup
Helping the team maintain their burndown chart
Setting up retrospectives, sprint reviews or sprint planning sessions
Shielding the team from interruptions during the sprint
Removing obstacles that affect the team
Walking the product owner through more technical user stories
Encouraging collaboration between the Scrum team and product owner
Notice the common theme… Almost everything that ties into Scrum will be directly
facilitated by the Scrum Master or create a situation where the Scrum Master can provide
guidance. The point here is to show that the Scrum team should not overly concern
themselves with Scrum and stay focused on the job of software development. Similarly, the
product owner can continue honing in on business needs with the confidence that the
Scrum Master will pull her in at key points like sprint reviews. The Scrum Master champions
these duties to ensure that Scrum process doesn’t impede team progress.
GURUNATH VELLANKI
Do we need a dedicated Scrum Master?
Although these tasks are often enough to keep someone busy all day, not every
Scrum Master is “just” the Scrum Master. Some teams may choose to elect a
developer or tester to become Scrum Master for the team, because they don’t feel
the position merits full-time personnel. Based on the duties a Scrum Master
performs, your team may be able to get away without a dedicated
individual if:
Your product owner knows everything about the customer and is always there
for the development team without guidance from the Scrum Master.
Your dev team has such a healthy communication culture that daily standups
are redundant and add to the overall process overhead.
The burndown chart and other artifacts are maintained automatically and don’t
create any overhead for the development team.
The team operates free of distractions and can easily clear all obstructions on
their own.
It’s reasonable for such a mature team to select a Scrum Master from within, but
these high levels of cohesion aren’t likely from organizations that are just starting
out. Whether or not your team has exceptional expertise, the Scrum Master role is
crucial because it acts as a buffer between the team and any process overhead
Scrum can create.
GURUNATH VELLANKI
Scrum Masters…
Take on the administrative, coaching and
leadership roles that make Scrum development
possible.
Ensure the Scrum process doesn’t impede
team progress.
Act as a buffer between the team and process
overhead, so each team member can focus on
shipping the software on time.
GURUNATH VELLANKI
Meetings
Facilitating meetings for the team. This includes:
preparing
moderation
post processing
Holding retrospectives. Retrospectives are special
meetings, therefore I count them separately.
GURUNATH VELLANKI
Team Dynamics
Coaching team members (e.g. with one-on-
one coachings).
Mediating through conflicts.
Helping the team to make decisions.
Fostering the developer team’s self-organisation.
Mediating the general conflict of goals between
development team (high technical quality) and
product owner (more features).
GURUNATH VELLANKI
Learning
Continuing learning regarding everything Agile (e.g. visit
user groups, attend conferences, read books, write blogs,
etc.).
Consulting team members regarding everything Agile.
Helping the team to create information radiators.
Giving feedback to the team.
Encouraging the use of Agile Engineering Practices within
the development team (this is ahuge field to spent a Scrum
Master’s time in, including e.g. one click releases,
continuous delivery, feature flags, and many more).
Challenge team with Agile management innovations
(e.g. FedEx-Days).
Exchanging constantly with other Scrum masters in the
organisation (e.g. through community of practice).
GURUNATH VELLANKI
Product
Helping to write or split user stories.
Helping to write or adapt product visions.
Helping to order product backlog items.
Helping with the release planning.
Being familiar with the team’s work (i.e. the product).
GURUNATH VELLANKI
Big Picture
Bringing people together who should talk to each other.
Keeping in touch with every stakeholder regularly.
Helping the team to report to management.
Helping to further the Agile community within the organisation.
Organizing exchange events like Open Spaces for the team, its
stakeholders, and its organisation.
Sharing insights throughout the company (micro-blogging,
blogging, internal conferences, etc.).
Being a contact person for everyone in the team and their
stakeholders regarding Agile.
Giving learning opportunities to people in the organization (e.g.
talks or workshops) and letting them learn important Agile
concepts like
GURUNATH VELLANKI
Change & Mirror
Change
Helping the team to get rid of impediments.
Suggesting new metrics for the team as catalysts for change.
Mirror
Reflecting Agile and Scrum values to the team.
Reminding the team of their arrangements (e.g. policies).
Helping the team to continuously improve their process.
Reflecting issues to the team through observation from outside
of the team.
Asking open questions.
Checking all the models the team uses (e.g. Sprint backlog,
metrics, etc.) and show them differences between the model and
the real world.
GURUNATH VELLANKI
Miscellaneous
Helping the team to keep focus (e.g. by acting as a
buffer between external distractions and the team).
Helping the team to maintain their Scrum tools (Story
board, Action board, charts, backlogs, etc.).
Helping team and product owner to find a suitable
definition of done
definition of ready.
GURUNATH VELLANKI
Empowering Teams
The number of “un empowered” teams alleging to be doing Scrum is appalling! Two significant factors often
prevent Scrum teams from becoming empowered, ultimately leading to their failure:
1) Organizational command and control behaviour 2) Specific Scrum Master failings
Both of these factors are something a ScrumMaster can (and should) address.
Symptoms
Sprint Planning Sessions. Symptoms include managers or Scrum Masters:
Questioning (or influencing) team task estimates.
Directing the order in which tasks should be completed during a sprint.
Directing which team members should be assigned to specific tasks.
Daily Scrums. Symptoms include:
Providing status to the Scrum Master instead of providing status to the team.
Zombie-like monotone responses, such as "I did this. I will do that. I have no impediments." Daily
Scrums of this nature rarely lead to the collaborative post-Scrum discussions where decisions are
made and impediments are circumvented.
For a great discussion on how to get your daily Scrum back on track,
Managers and/or ScrumMasters who take charge of the session and state their observations first.
General Meetings. Symptoms include team members that:
Ramble aimlessly. , Hijack meetings and won’t relinquish control back to the team.
Do not participate. , Get up and leave meetings.
Force their “expert” opinion on the team inflexibly.
Argue about everything.
For great techniques to handle these team meeting dysfunctions,
GURUNATH VELLANKI
Empowering Teams
Causes
"Command and Control" Style Managers (including Scrum Masters)
All of the problems described under “Dysfunctional Sprint Meetings”
are caused directly by managers (including ScrumMasters) who usually
come to Scrum armed with years of ingrained, directive behaviors. The
ScrumMaster needs to work with these managers to get them to let go.
It’s the ScrumMaster’s responsibility to educate management and help
them understand that the process is all about trust. If team members
cannot be trusted to determine their work, teams will never properly
“commit” to completing a sprint goal, nor will they ever feel the desire
to make the key decisions that they should be responsible for.
The ScrumMaster also needs to work with managers to help them to
allow others to provide feedback during sessions before they chime-in.
If the manager cannot be controlled in this area, they may need to be
removed from the process.
If the ScrumMaster is the problem, then an agile coach needs to be
brought-in to educate the ScrumMaster (or have the ScrumMaster
removed and replaced if necessary).
GURUNATH VELLANKI
Empowering Teams
Cure - To ensure team empowerment, the Scrum Master must work diligently on all of his
or her responsibilities.
Resolve Conflicts: The ScrumMaster is responsible for removing certain barriers
* Between individual developers (or between any individual team members)
* Between developers and test engineers (especially when working together cross-functionally)
* Between the development team and the product owner.
If the ScrumMaster does not have the skills to deal with team conflict, a professional facilitator
should be consulted.
Handling Impediments: A ScrumMaster must actually work to help remove impediments
reported during the daily Scrum. If it looks like an impediment cannot be removed for some
reason, it becomes a condition of reality. For these conditions, the ScrumMaster must work
with the team to circumvent the impediment. If an impediment requires more than one day
for removal, the ScrumMaster must communicate this information back to the team so that
they know the ScrumMaster is making an effort on the team's behalf.
Protecting the Team: The ScrumMaster must protect the team from disruptive outside
influences. (Examples include salespeople directly requesting estimates from team members
for prospective clients, support staff directly contacting team members for help with customer
bugs, consultants at client sites calling team members with installation, conversion, or
configuration problems for a new installation, etc.) The ScrumMaster must also protect the
team from attending unnecessary meetings. Most meeting owners will be able to tell if a team
member really needs to attend a meeting.
GURUNATH VELLANKI
Empowering Teams
Scrum teams feel truly empowered when they understand that the
ScrumMaster is actually looking out for the team and will protect the team
from outside influences that can rob the team of its power. More
specifically, the ScrumMaster needs to
Eliminate (or sufficiently reduce) “command and control" management
practices so that teams can run their own sprint planning sessions in the
areas of task estimates, task sequencing, and task assignments, as well as
run sprint reviews and retrospectives openly and honestly so that they
actually make a difference going forward.
Ensure that dysfunctional meeting participants are controlled, even if by
a third-party facilitator.
Ensure that barriers between team members are removed, even if by a
third-party facilitator.
Effectively work with the team to remove impediments, proving a level of
true commitment to the team.
Protect the team from stressful outside influences and unnecessary
meetings, enabling the team to work together with reduced interruption.
GURUNATH VELLANKI
7 Tips to make retrospective a worthwhile
1. Share the outcomes of the previous meeting
2. Give a pat on the back
3. Coach them to be prepared
4. Change the meeting pattern
5. Press the SOS button: Escalation
6. Show them trends based on metrics
7. Say thank you
GURUNATH VELLANKI
5 Reasons Why a Physical Scrum Board Rocks
1. It promotes collaboration and conversation
2. It's a focal point
3. It promotes transparency
4. It gets updated
5. It's more interactive and fun
GURUNATH VELLANKI
Why training is important in Agile transformation
GURUNATH VELLANKI
Jeff Patton
Agile Product Design
jpatton@acm.org
GURUNATH VELLANKI
The product owner role comes from the specific
Agile process Scrum
GURUNATH VELLANKI
The product owner plans the product in layers
Product Release
or Project How can we release
value incrementally?
What business objectives
What subset of business
will the product fulfill?
objectives will each
Product Charter release achieve?
Elevator Pitch What user constituencies
will the release serve?
What general capabilities
(big stories) will the
release offer?
Release plan
Iteration
What specifically will we
build? (user stories) Story (Backlog Item)
How will this iteration What user or stakeholder need will
move us toward release the story serve?
objectives? How will it specifically look and
Iteration Plan behave?
How will I determine if it’s
completed?
Story Details
Acceptance Tests
GURUNATH VELLANKI
The Planning Onion can grow to include
product portfolios and business strategy
Product Release
or Project How can we release
Product or Project value incrementally?
What business objectives
will the product fulfill? What subset of business
objectives will each
Product Charter
Release release achieve?
Elevator Pitch
What user constituencies
will the release serve?
Iteration What general capabilities
(big stories) will the
release offer?
Release plan
Iteration Story
What specifically will we
build? (user stories) Story (Backlog Item)
How will this iteration What user or stakeholder need will
move us toward release the story serve?
objectives? How will it specifically look and
Iteration Plan behave?
How will I determine if it’s
completed?
Story Details
Acceptance Tests
GURUNATH VELLANKI
The Planning Onion can grow to include
product portfolios and business strategy
Product or Project
Release
Iteration
Story
GURUNATH VELLANKI
The Planning Onion can grow to include product
portfolios and business strategy
Business Strategy
Product Portfolio
Product or Project
Release
Iteration
Story
GURUNATH VELLANKI
The Product Owner Is a:
Subject Matter Expert Business Advocate
Understand the domain well enough to ▪ Understand the needs of the
envision a product organization paying for the
Answer technical questions on the software’s construction and select a
domain for those creating the product mix of features that serve their goals
End User Advocate
Describe the product with Communicator
understanding of users and use, and a ▪ Capable of communicating vision
product that best serves both and intent – deferring detailed
Customer Advocate feature and design decisions to be
made just in time
Understand the needs of the business
buying the product and select a mix of
features valuable to the customer Decision Maker
▪ Given a variety of conflicting goals
and opinions, be the final decision
maker for hard product decisions
GURUNATH VELLANKI
Product Owner Responsibilities
Participate daily
Evaluate product at
Be available to answer end of Sprint and add
questions and clarify or remove stories from
details on user stories backlog as necessary
GURUNATH VELLANKI
Design and Coded Features Pass Back and Forth
Between Tracks
Sprint 0 Sprint 1 Sprint 2 Sprint 3
• planning • gather user input • gather user input • gather user input
• data gathering for iteration 3 for iteration 4 for iteration 5
Product Owner
support dev
Development Team
time
GURUNATH VELLANKI
Agile Metrics
Sprint goal success rates: A successful sprint should have a working product feature
that fulfills the sprint goals and meets the scrum team's definition of done: developed,
tested, integrated, and documented. Throughout the project, the scrum team can track
how frequently it succeeds in reaching the sprint goals and use success rates to see
whether the team is maturing or needs to correct its course.
Defects: Defects are a part of any project, but agile approaches help development teams
proactively minimize defects. Tracking defect metrics can let the development team
know how well it's preventing issues and when to refine its processes.
The number of defects and whether defects are increasing, decreasing, or staying the
same are good metrics to spark discussions on project processes and development
techniques at sprint retrospectives.
Time to market: Time to market is the amount of time an agile project takes to provide
value, either through internal use or by generating income, by releasing working
products and features to users.
Return on investment: Return on investment (ROI) is income generated by the
product, less project costs: money in versus money out. On agile projects, ROI is
fundamentally different than it is on traditional projects. Agile projects have the
potential to generate income with the very first release and can increase revenue with
each new release.
GURUNATH VELLANKI
Agile Metrics
New requests within ROI budgets: Agile projects' ability to quickly generate
high ROI provides organizations with a unique way to fund additional product
development. New product features may translate to higher product income. If a
project is already generating income, it can make sense for an organization to roll
that income back into new development and see higher revenue.
Satisfaction surveys: A scrum team's highest priority is to satisfy the customer. At
the same time, the scrum team strives to motivate individual team members and
promote sustainable development practices. A scrum team can benefit from
digging deeper into customer and team member experiences through satisfaction
surveys.
Velocity: The efforts delivered in one standard size (team of 7) sprint
Team member turnover: Agile projects tend to have higher morale. One way of
quantifying morale is by measuring turnover through a couple metrics:
Scrum team turnover: Low scrum team turnover can be one sign of a healthy
team environment. High scrum team turnover can indicate problems with the
project, the organization, the work, individual scrum team members, burnout,
ineffective product owners forcing development team commitments, personality
incompatibility, a scrum master who fails to remove impediments, or overall team
dynamics.
GURUNATH VELLANKI
Scrum Best Practices
Burn down charts can be used to monitor sprint status.
Graphical representations are better than tabular list views
in planning.
Planning poker is a useful way to determine sprint item
finish durations. And using Fibonacci numbers is a good
practice for planning poker numbers.
ROI (Return on Investment) values are useful to determine
item priorities in a sprint. Planning poker can be used to
determine ROI values.
Using a board and simple planning/reporting tools (e.g.
excel, sprintometer, projectsimple) are important and
enough as process quality equipment.
Scrum methodology does not offer documenting
everything, but this does not mean "no documentation".
Really needed documentation can be done as required.
GURUNATH VELLANKI
Scrum Best Practices
Daily meetings must not be longer than 15 minutes. Scrum is an agile
methodology and no one needs to listen to other members' problem details.
These details may be discussed after the daily meeting with the scrum
master with only required subset of team members.
Stand up meeting style is better for daily meetings, to keep meeting short.
Also meeting location and time are recommended to be the same for each
day.
Product backlog may contain items which will not be developed. According
to ROI values, some items may not be developed and this is normal.
Product backlog should contain all possible items anyway. Give backlog
items ID numbers, to manage simply.
Sprint length (in weeks) changes are not recommended. But according to
the sprint retrospective meeting results, sprint week lengths may be
changed if there are really important reasons.
6 hours per a day is a realistic planning input. Total sprint hour capacity can
be calculated as: (number of team members) * (number of sprint days) * 6
hour
GURUNATH VELLANKI
ScrumButs and Modifying Scrum
ScrumButs are reasons why teams can’t take full advantage of Scrum to solve their
problems and realize the full benefits of product development using Scrum.
ScrumButs mean that Scrum has exposed a dysfunction that is contributing to the
problem, but is too hard to fix. A ScrumBut retains the problem while modifying
Scrum to make it invisible so that the dysfunction is no longer a thorn in the side of
the team.
A ScrumBut has a particular syntax: (ScrumBut)(Reason)(Workaround)
ScrumBut Examples:
"(We use Scrum, but) (having a Daily Scrum every day is too much overhead,) (so
we only have one per week.)"
"(We use Scrum, but) (we can't build a piece of functionality in a month,) (so our
Sprints are 6 weeks long.)"
"(We use Scrum, but) (sometimes our managers give us special tasks,) (so we don't
always have time to meet our definition of done.)"
Sometimes organizations make short term changes to Scrum to give them time to
correct deficiencies. For example, "done" may not initially include regression and
performance testing because it will take several months to develop automated
testing. For these months, transparency is compromised, but restored as quickly as
possible.
GURUNATH VELLANKI
SAFe
GURUNATH VELLANKI
GURUNATH VELLANKI
GURUNATH VELLANKI
GURUNATH VELLANKI
GURUNATH VELLANKI
GURUNATH VELLANKI
GURUNATH VELLANKI
GURUNATH VELLANKI
Thank You
GURUNATH VELLANKI