You are on page 1of 144

Introduction to

Agile SCRUM Methodology

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)

• Certified Agile Coach • 35+ years of total experience as IT Delivery Manager.


Certifications

• Expert in Strategy Planning * Program / Delivery

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

Expert in Conducting Management and


Agile Coach, Consultant and Corporate Technical trainings with 25+ years of

Training
Role

Trainer. Conducts workshops to resolve experience. Expert on Conducting


Delivery issues. Expert on Customized Customized Agile Workshops to
Trainings, resolve Agile implementation issues.
Conducts activity base trainings

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

People collaborating together to


build high quality products that
meet customer needs at a
sustainable pace

GURUNATH VELLANKI
EMPIRICAL PROCESS

Any process that exhibits transparency


so that teams can inspect their progress
with respect to plan and adopt their plan,
process, design etc to achieve the Goal

GURUNATH VELLANKI
AGILE MANIFESTO

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

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.

Requirements Design Code Test

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.

When to use Agile?

GURUNATH VELLANKI
TOP 10 REASONS AGILE PROJECTS FAIL

1. Transitioning without proper Training/Coaching


2. Resistance To change
3. Seating Arrangement
4. Poor Communication/Collaboration
5. Lack of Transparency
6. Fear
7. Process without Principles
8. Not empowering the teams
9. No proper Retrospection
10.Still no cross-functional team

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)

PRINCIPLES Instrumental factors which need to be met.


1. Focus on the business need 1. Acceptance of the Atern philosophy before
2. Deliver on time starting work.
3. Collaborate 2. Appropriate empowerment of the Solution
4.Never compromise quality Development Team.
5. Build incrementally from firm foundations 3. Commitment of senior business management
6. Develop iteratively to provide the necessary Business
7. Communicate continuously and clearly Ambassador (and Business Advisor)
8. Demonstrate control involvement.
4. Incremental delivery
5. Access by the Solution Development Team
to business roles
6. Solution Development Team stability.
7. Solution Development Team skills.
8. Solution Development Team size.
9. A supportive commercial relationship.

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.

Letter Meaning Description


Describes a requirement that must be satisfied in the final
M MUST
solution for the solution to be considered a success.
Represents a high-priority item that should be included in the
S SHOULD solution if it is possible. This is often a critical requirement but
one which can be satisfied in other ways if strictly necessary.
Describes a requirement which is considered desirable but not
C COULD
necessary. This will be included if time and resources permit.
Represents a requirement that stakeholders have agreed will
not be implemented in a given release, but may be considered
W WON'T for the future. (note: occasionally the word "Would" is
substituted for "Won't" to give a clearer understanding of this
choice).
GURUNATH VELLANKI
Key Terms and Examples (2)
Agile Method Term Examples
eXtreme Values Communication, simplicity, feedback, courage,
Programming respect
(XP) Activities Coding, testing, listening, designing
Techniques Pair programming, test driven development,
continuous integration, collective code
ownership
Feature Driven Activities Plan by feature, design by feature, build by
Development feature
Best practices Domain object modelling, developing by feature,
individual class (code) ownership, visibility of
progress and results
Scrum Techniques Team creation, backlog creation, project
segmentation, scrum meetings, burn down
charts
Phases Review release plans, sprint, sprint review,
closure

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

It is an entry criteria agreed by Product Owner and


development Team to start the development of Product
Backlog item.

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

Represents the solution side of the Product Development

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

Represents the people side of the Product Development

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

It is an integrated increment of final product built iteratively

Contains (for a software product)


Software package
Release notes
User Manual
Support documents,
Etc.

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

It is a measure of how much work a


Scrum Team can do in a Sprint

It is calculated at the end of the Sprint


by summing up story points associated
with Product Backlog items done

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

 Maintains a prioritized backlog for the product


 Prioritizes features according to business value

 Decides on release date and content


 Is responsible for the ROI of the project
 Can change features and priority every sprint
 Accepts or rejects work results

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

 Commits to the Sprint goal and specifies work results


 Demos work results to the Product Owner

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

Inputs Sprint Tested Code

 Plan sprint durations around how long you can


commit to keeping change out of the sprint

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.

 Can Scrum meetings be replaced by emailed


status reports?
 No
 Entire team sees the whole picture every day
 Create peer pressure to do what you say you’ll do
GURUNATH VELLANKI
Sprint Review Meeting
 Team presents what it accomplished during the sprint
 Typically takes the form of a demo of new features or
underlying architecture
 Informal
 2-hour prep time rule
 Participants
 Customers
 Management
 Product Owner
 Other engineers

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

There are 20 artists 1. 20 web pages must be on the website


currently exhibiting at 2. Each artist must be listed on the
New Art Gallery Create web page for the gallery. Each artist page with their bio
1 Website
1Gallery Owner
each artist should be provided 1 3. At least one piece of art should be
page to showcase their described and a picture included on
art each page

1. The main page of the website should


New gallery wants to
describe the gallery and its mission.
build a community
New Art Gallery Create main Gallery 2. The main page of the website should
2 Website
1Gallery Owner
Webpage
between the artists,
have a link to each of the artist pages
the gallery & the
that are currently exhibiting at the
customers.
gallery

1. Customers should be able to send a


Customers should be message to the artist. There is no
able to chat directly requirement that the artist respond
New Art Gallery Artist & Customer with artists to learn immediately.
3 Website
2Gallery Owner
communication more about any art 2. Artists must have a way to respond
pieces they may be to the customer
interested in. 3. The interaction between artist and
customer can be public or private.

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

 No more than 300 tasks in the list


 If a task requires more than 8 hours,
it should be broken down
 Team can add or subtract items
from the list. Product Owner is not
allowed to do it

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

Focus on… Think about how you will…


Establish and make visible the vision and the pipeline of work that the team
Product
will do
Team Ready the team with knowledge, skills, tools, and processes
Install, configure, and test tools; set up workrooms and collaboration
Environments
spaces, creating visibility
Defining the high-level architecture and design goals to guide emergent and
Architecture
incremental delivery of business value

The time required to complete Iteration 0 will vary; it depends on


the needs of the team and the
product. Typically it takes one week for each three months of
scheduled project-time. The team
should time-box each week of Iteration 0 to ensure they don’t spend
more time than needed.
GURUNATH VELLANKI
Activity
Sprint Zero Checklist Description
Vision Product Champion has prepared vision statements for the project and release.
The team understands and agrees to the vision, drivers, and expected outcomes for the
release.
Product Backlog Features have been prioritized and estimated.
High level architectural milestones have been specified.
Story Estimation Stories have been decomposed and right sized.
Validation criteria for stories are understood.
Stories have been estimated for first few iterations’ work.
Iteration Backlog Iteration length is set.
Iteration backlog is established and visible.
The team has committed to Iteration 1 plan.
Stories are assigned to the first few iterations.
Team The team is staffed with all of the needed roles, dedicated to the release, and co-located as
much as possible.
The team has received required training: Lean-Agile software development,
Test-Driven Development, engineering practices.
Artifacts and deliverables are determined (and visible).
Testing Definition of done has been established and documented (unit, integration, acceptance).
Agreements
Team Environment Lessons learned from previous releases have been intentionally incorporated.
Tools for testing, coding, integrating, and building have been selected and installed.

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.

“Left to their own devices,


stakeholders will set 85% of the
requirements at high priority, 10%
at medium, and 5% at low priority.
This doesn’t give the project team
much to work with.”
-Karl E. Wiegers

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):

 Grocery shopping  Pick up dry cleaning


 Soccer game for the kids  Get dressed for formal dinner
 Purchase BDay gift for sister  Shower / personal grooming
 Schedule baby sitter  Return defective merchandise
 Make reservations at for refund
restaurant for 7 p.m. dinner  Repair chipped windshield
 Get gas for the car  Eat lunch
 Wash the car  Fold and iron clean laundry
 Weed the front yard  Replace broken sunglasses
 Pick up girl scout cookies for  Mail Credit Card payment
delivery to buyers
You can’t do them all – how do you decide? What is your technique?
• Which items do you choose?
Page 90
GURUNATH VELLANKI
What Drove Your Decisions?
 Personal Value of the Item?
 The Risk Factor? Assumptions?
 Difficulty?
 Likelihood of Getting it Done on Time?
 Simply a “Must Have?”
 How Closely Linked it was to other Items? (Geography,
type of task, etc.)
 Unspoken Agreement with the Spouse/Friend?
 Personal Deadline?

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

 User Story Points


Story points are a measure of size, not time or effort. This is a change in perspective
for many teams since they are used to thinking in terms of real time

 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

 Planning poker / Scrum poker


Planning poker, also called Scrum poker, is a consensus-based technique for
estimating, mostly used to estimate effort or relative size of user stories in software
development. It is a variation of the Wideband Delphi method.

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

 During the Agile journey, training for technical and


business teams, with specific focus on Agile
fundamentals followed by Scrum, can help in adding
more value to the transformation.
 With training, the teams become strong and
knowledgeable, and they can also adapt to the change
easily.
 Seminar sessions or speeches by external consultants
and Agile experts can also add more value to the
implementation. The teams will be equipped with
immense Agile knowledge, thereby making quick wins
possible.

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

The Product Owner role is generally filled by a single


person supported by a collaborative team

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

Verify stories are done


Create and maintain the based on acceptance
product backlog criteria

Organize the backlog into Specify objective acceptance


incremental releases criteria for stories
• Communicate Business Goals, Customer Goals, End User Goals
• Coordinate involvement of SMEs, users, and business stakeholders
• Coordinate with other product owners to insure coherence of product and releases

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

• design for features features features


iteration 1 • design iteration 2 • design iteration 3 • design iteration 4
features – high features features features
technical • support iteration 1 • support iteration 2 • support iteration 3
Team

requirements, low development development development


user requirements • validate iteration 1 • validate iteration 2
support dev features features

support dev
Development Team

• development implement iteration implement iteration implement iteration


environment 1 features 2 features 3 features
setup fix iteration 1 bugs fix iteration 2 bugs if
• architectural if any any
“spikes”

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

You might also like