Agile Scrum

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED
AGENDA
Waterfall vs Agile Process Framework
Agile Myths
Agile Manifesto & Agile Principles
Agile Methodologies (SCRUM & XP)
Agile Requirements Management (User Stories)
Scrum Framework
Planning & Estimating in SCRUM
Agile Testing & Quality
Agile Adoption
Case Study & Simulation
~ Winning isn't getting ahead of others. It's getting ahead of yourself Roger Staubach

PROCESS FRAMEWORK
Traditional Water-fall
Analysis Design Develop Test Deploy

WATERFALL REQUIRES PERFECT VISION
Waterfall calls for a fully formed idea up

front.
And, doing it on time requires dead
accurate estimation.
1 2 3 4 5
4 Jeff Patton, all rights reserved, www.AgileProductDesign.com

AGILE EXPECTS VISION SHIFT
builds a rough version, validates it, then slowly builds up
Iterative quality
A more iterative allows you to move

from vague idea to realization making
course corrections as you go.stop
when diminishing returns are
encountered!
1 2 3 4 5
5
Jeff Patton, all rights reserved, www.AgileProductDesign.com
AGILE = EARLY VALUE
Traditional Process Agile Process
Do we have half 20% done

a solution yet? (100% usable!)
Analysis Analysis
Design Design
Coding Coding
Testing Testing
Time Time

ARE WE DELIVERING QUICKLY?
Conventional projects take too Lean (agile) methods link

long and often miss the mark developers and users to hit the
mark quickly

AGILE MYTHS
Myth No. 1: Agile Means 'No Commitment
Myth No. 2: Agile Development Is Not Predictable
Myth No. 3: Agile Is a Silver Bullet
Myth No. 4: Agility Helps in Every Case
Myth No. 5: There's Only One Way to Do Agile
Other Myths
Myth No. 6: Agile Doesn't Need Up-Front Design
Myth No. 7: Agility Is Pain-Free

AGILE MANIFESTO
Facilitating change is more effective than attempting to prevent it. Learn to trust in your ability
to respond to unpredictable events; its more important than trusting in your ability to plan for
disaster Martin Fowler & Jim Highsmith
As a result of the formation of the Agile Alliance in Feb 2001, 14 individuals came up with this
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
While we value the items on the right, we value the items on the left more

PRINCIPLES OF AGILE MANIFESTO
Satisfying customer is top priority
Welcome changing requirements, even late in development
Deliver working software frequently
Development teams and business work together
The primary measure of success is working software
The Team regularly reflects on work
Build projects around motivated people
The most efficient and effective method of conveying information to and within
development teams is face-to-face communication
Continuous attention to technical excellence and good design
Simplicity the art of maximizing the amount of work not doneis essential
The best architectures, requirements and designs emerge from self-organizing teams
Agile processes promote sustainable development The sponsors, developers and users
should be able to maintain a constant pace in definitively.

SYSTEMS THINKING PROJECTS SUITED FOR AGILE
Suited for Agile

projects
The most appropriate projects for agile are, ones with aggressive deadlines, a
high degree of complexity, and a high degree of novelty (uniqueness) to them

SCRUM FRAMEWORK

SCRUM VALUES

XP PRACTICES

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

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

RELATIVE SIZING
Size Value
Priority Description (from (from Product
Team) Owner)
1 Feature A 3 Extra-High
2 Feature B 5 Extra-High
3 Feature C 3 High
4 Feature D 8 Extra-High
5 Feature E 5 High
6 Feature F 2 Medium
7 Feature G 13 High
8 Feature H 3 Low

THE PRODUCT BACKLOG
Size
Priority Description (to
build) Total = 40 points
1 Feature A 3 Velocity = 14 points per Sprint
2 Feature B 4
3 Feature C 3 Time to complete =
4 Feature D 2
40/14 = 2.8 Sprints
5 Feature E 4
6 Feature F 4
7 Feature G 3 Used for release
planning
8 Feature H 5
9 Feature I 2
10 Feature J 4
11 Feature K 2
12 Feature L 4


AGILE RELEASE PLANNING

EPIC, THEMES AND STORIES
Epics
Themes

Software requirements is a communication problem
This is normally between customers (incl. users/analysts/domain experts), and a
technical team - It is all about collaboration
Distinguish between Functional and non-functional requirements
Vision - Goals - Requirements - Features - User Stories
High Level Requirement represents what is to be designed

Low Level Requirement represents how to carry out the design

Requirements Gathering
Techniques for Requirement Gathering
Prototyping Create screen prototypes for clear s/w requirements

Use Cases (Scenario-driven approach) and Storyboards
Modeling (DFDs, etc.,)

REQUIREMENTS MANAGEMENT USER STORIES
User Stories
As a (role) I want
(something) so that
(benefit).

PRINCIPLES OF USER STORIES THE 3 CS
Card
User Story information is lightweight. It fits onto a single

index card.
Conversation
When the story is selected for a Sprint, further details are

finalized in conversations with the Product Owner
Confirmation
Acceptance criteria are added to the User Story, to confirm

the feature was implemented properly

User Stories - An Example
As a customer service representative, I can search for a customer so that I can view
their account details.
When searching by a valid account number, the account is shown

When searching by a valid name and SSN, the account is shown
If no results are found, show appropriate message
Acceptance tests?

INVEST criteria for User Stories
Independent
Negotiable
Valuable (to users/customers)
Estimatable
Small
Testable

Story Smells
Interdependent Stories
Goldplating
Too Many Details (not INVEST)
Thinking Too Far Ahead (waterfall mindset)

Agile Prioritization Technique - MoSCoW
Must have (or Minimum Usable Subset)

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

AGILE PLANNING
Scheduling your iterations
Creating User Stories
Assigning Story points to User Stories
Identifying the Product Owner
Measuring Velocity

AGILE ESTIMATION
Estimating User Stories
When will you be done with these features
Best approach for estimating stories would be one that:
Allows us to change our mind when we have new information on a story

Works for both epics and small stories
Does not take a long time
Is tolerant of imprecision in estimates
Can be used to plan releases

ESTIMATION ..CONTD
Agile Estimating Methods
Story Points (Fibonacci Series)
Ideal days
T-Shirt Sizing
Estimation Responsibilities
Developer
Giving honest estimates
Estimating as a team
Consistent. Example, all 2 point estimates are similar
Customer
To participate in estimation meetings by answering questions and clarifying
Not allowed to estimate stories yourself

AGILE ESTIMATION
Measure of Size
For Sequential - Line of Code, Functional Points
For Agile Story Points, Ideal days
IDEAL DAYS Story Point

How long something would take if The bigness of a task
its all you worked on Influenced by
you had no interruptions How hard it is
and everything you need is How much of it there is
available Relative values are what is important:
A login screen is a 2.
The ideal time of a basketball game is 40
A search feature is an 8.
minutes
Points are unit-less
Four 10-minute quarters
The elapsed time is much longer (2+ hours)

AGILE ESTIMATION STORY POINTS
Use the right units
Can you distinguish a 1-point story from a 2?

How about a 17 from an 18?
Use 0 and
Use a set of numbers that make sense; I like:
1, 2, 3, 5, 8, 13
if you
like
Stay mostly in a 1-10 range

AGILE ESTIMATION PLANNING POKER
An iterative approach to estimating Steps
Each estimator is given a deck of cards, each card has a valid estimate written
on it
Customer/Product owner reads a story and its discussed briefly
Each estimator selects a card thats his or her estimate
Cards are turned over so all can see them
Discuss differences (especially outliers)
Re-estimate until estimates converge

AGILE ESTIMATION
Planning Poker
3 5
5 5
5

AGILE ESTIMATION
Story Points
1 2 3 5 8
13 20 40 100 ?

AGILE ESTIMATION
Planning Poker - An Example
Round Round
Estimator
1 2
Sheila 3 5
Raj 8 5
Suresh 2 5
Annie 5 8
www.planningpoker.com

VELOCITY
In Scrum, velocity is how much product backlog effort a team can handle in one
sprint.
This can be estimated by viewing previous sprints, assuming the team

composition and sprint duration are kept constant. It can also be established on
a sprint-by-sprint basis, using commitment-based planning.
Once established, velocity can be used to plan projects and forecast release and
product completion dates.

AN EXAMPLE
An Example with Velocity = 14
Sprint 1 Sprint 34
Story A Story B Story H Story J
5 8 13
Story I 8
Story E
1 5
Sprint 2
Story C Story F
3 3
Story D Story G
5 3 COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED
VELOCITY CHART
Projection Based on Velocity
40 Mean (Best 3) = 37
Mean (Last 8) = 33
30 Mean (Worst 3) = 28
Points
20
10
0 Sprints
1 2 3 4 5 6 7 8 9

AGILE QUALITY
Planning for Quality
What is Quality and how is it measured

TDD & Test Automation
Refactoring
Pair Programming
Continuous Integration
Definition of Done (DOD)
Technical Debt
Managing Defects
Coding & Testing practices

QUALITY GOALS FOR AGILE TEAMS
Define and measure the quality of your application
Agile process gives QA as well as management to change or prioritize tasks at end of
each iteration
The quality goal metrics accomplishes two things
Establish protocol between product management and engineering what are the
expectations from the product
Empower QA to have product management/development prioritize between new
feature development vs fixing old bugs
Quality Goals for Applications

Non-executed test cases: The number to achieve is 0.
High severity Open Bugs/Total Bugs
Medium severity Open Bugs/Total Bugs
Low severity Open Bugs/Total Bugs
Untargeted Bugs

TEST DRIVEN DEVELOPMENT (TDD)

REFACTORING
If it aint broken, why fix it
Code is unreadable
Hard to modify
Duplicated code is hard to modify
Complex code is hard to modify
Refactored code is easy to understand
Cheaper to modify
Refactored code shows - Change to its internal structure, But no
change to Observable behavior
A disciplined technique for restructuring an existing body of code, altering its internal
structure without changing its external behaviour", undertaken in order to improve some of
the non-functional attributes of the software

WHERE TO START
Look at the Code
Sniff the code Does it Smell?
Duplicated Code? Loooong method? - L A R G E Class?
The Refactoring cycle
1. Choose the worst smell
2. Select a refactoring
3. Apply the refactoring
4. Run all the tests

PAIR PROGRAMMING - DEFINITION
Pair programming is an agile software development technique in which
two programmers work together at one workstation. One, the driver,
types in code while the other,
the observer (or navigator, reviews each line of code as it is typed
in. The two programmers switch roles frequently.

PAIR PROGRAMMING - ADVANTAGES
Continuous Review
Less Defects Defects caught early
Improvement in the quality of Design
Better problem solving
More economical
Pair-pressure Ensures timely delivery
Rapid hands-on approach to learning
Better induction of new team members
Less distraction leading to higher productivity
Better team building and communication

CONTINUOUS INTEGRATION
Automated Process
Build Test Deploy
In a continuous way
- after each commit into versioning system
- at specific intervals (e.g., Nightly Builds)
Always a deployable release
Build and Test the entire system several times a day

Unit Test must run at 100% before integration
Unit Test must run at 100% after integration
Single integration machine

CORE PRACTICES
Single Source Repository
Automate Build
Automate Testing
Publish the latest distributable

DEFINITION OF DONE
The Team goal at the end of each Sprint is to be done
But what does done mean?
Coded?
Coded and tested?
Coded and tested with no defects remaining?
Shippable?
To be clear about what we mean, the Product Owner and Team must agree
on a Definition of Done
Defined at start of first Sprint Planning Meeting
Reviewed and possibly adjusted at each Sprint Planning Meeting
Should become more all-inclusive over time

DEFINITION OF DONE
For functionality to
be Done at the
end of a Sprint, it
must have
completed the
following steps.
For this team,

Product Backlog
items that dont
meet all these
criteria at the end
of the Sprintisnt
No. of Defects Permitted: No P1 or P2 Defects
Done.

SCOPE OF DONE
Extending the
Scope of DONE
as far as possible

TECHNICAL DEBT
Technical debt (also known as design debt or code debt) is a metaphor referring
to an eventual consequence of poor or evolving software architecture and
software development within a codebase.
The debt can be thought of as work that needs to be done before a particular job
can be considered complete.
As a change is started on a codebase, there is often the need to make other
coordinated changes at the same time in other parts of the codebase or
documentation. The other required, but uncompleted changes, are considered
debt that must be paid at some point in the future

MOUNTING TECHNICAL DEBT
Mounting TD
ASPECTS OF TECHNICAL DEBT
Organic architecture
Little refactoring
Lack of automated Unit Tests

Poor/in-consistent Code
standards
Other Aspects of Technical Debt
Infrequent Integration
Mounting Regression Test effort
No Performance Testing
Bugs Known and Unknown

PREVENTING TECHNICAL DEBT
Practices to prevent Technical Debt
Agile Architecture Emergent architecture ( Continuous architectural refactoring

(neighborhood re-factoring)
Unit Tests - Track code coverage
Test Driven Development ( TDD & BDD)
Static Analysis
Continuous Integration
Automated functional tests
Regression & Performance
Peer Code Review
Pair Programming

MANAGING DEFECTS
Managing Defects

SCRUM HOW IT EVOLVED
Scrum was formalized by Ken Schwaber and Jeff Sutherland in 1995
It is now probably the fastest-growing approach to software development
globally
Used in many fortune 100 companies globally
Google Nokia
Sun Lockheed-Martin
Infosys HP
Wipro Agilent
TCS EMC
IBM GE

WHY SCRUM BECAME POPULAR
It can enable:
More business value sooner

Greater visibility
Improved productivity
Less waste
Higher quality
Stronger teams with better morale
Better return-on-investment for projects

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

This Slide provided by GoodAgile-The Scrum experts in Asia-www.goodagile.com @2010
SCRUM AN OVERVIEW
4
Transparency
Time-
boxes
Inspection 3
Artifacts
3
Adaptation
Roles
3 Key tenets/pillars Scrum Terminology

SCRUM ROLES
-The servant-leader
Customer voice who -People who deliver
who empowers the
establishes vision, customer value
team, facilitates the
prioritizes the work
process, and
and defines success
removes
criteria
impediments, if any
Scrum Master Scrum Team

Product Owner
-Someone interested
in the outcome of the
project
Stakeholders &
Users

CHICKENS AND PIGS

THE SCRUM TEAM
Product Owner
1 person
Owns vision for what should be produced
Creates and maintains the Product Backlog
Final decisionmaker about order of Product Backlog items
Team
7 people, +/- 2
Cross-functional (must include design, coding, testing, and any other skills required for
potentially shippable software at end of Sprint)
Self-organizing and self-managing
ScrumMaster
1 person
Removes the teams constraints and impediments (blocks)
Protects the team from disruption or disturbance
Coaches the Team and Product Owner to be successful with Scrum

This Slide provided by GoodAgile-The Scrum experts in Asia-www.goodagile.com @2010
SCRUM CEREMONIES / EVENTS
Sprint Planning meeting

Daily Standup
Sprint Review meeting
Sprint Retrospective

SCRUM PUTTING IT ALL TOGETHER

SCRUM ARTIFACTS
The 3 Scrum Artifacts are:
Product Backlog
List of functional & non-functional requirements
Sprint Backlog
Prioritized list of stories for a given Sprint
Sprint Burndown Chart

A chart showing completion of stories over time

3 KEY PILLARS OF SCRUM - EMPIRICISM
1. Transparency
Significant aspects of the process must be visible to those responsible for the
outcome.
2. Inspection
Scum users should frequently inspect scrum artifacts and progress towards a goal
to detect undesirable variance
3. Adaptation
High performing teams are those that adjust their work to meet the current reality.
Scrum offers both quantitative and qualitative techniques to assess how we can
avoid disaster and improve performance
Empiricism asserts that knowledge comes from experience and decision making is done based on what is known

4 TIMEBOXES Duration of
Timeboxes
during which something must be done.

How are we doing? 15 Minutes
A timebox is a fixed period of time,

Daily Scrum
Sprint Planning How do we do it? 4 Hours
Sprint Review
How did we do it? 2 Hours
Sprint Retrospective How do we do better? 2 Hours

RELEASE PLAN
Defined A high-level roadmap that forecasts when we will do what
Owned by Product Owner
Rules Only the PO can prioritize the backlog

Dependencies are offered by the team, must be considered
Velocity (average output per sprint) is required to know how
much to forecast for future sprints
Best Realistic Explains delivery dates as best case, worst case,

most likely scenarios
Practices Fresh Updated after each sprint

RELEASE PLANNING
Refer : http://www.scmpatterns.com/pubs/crossroads-mirror/2008-05-CMCrossroads.pdf

RELEASE PLANNING
Release planning is all about Steps in Release Planning
understanding what you're going to do Understand the goal

towards those themes in the next release. Understand the customer
requirement
It is setting a common understanding Prioritize and estimate the
amongst the teams on what the release backlog
will likely look like. It is not a commitment, Calculate the team velocity
rather a projection. It helps to establish a Create a release plan

common baseline across the teams.
Communicating the release plan
Updating the release plan

RELEASE PLANNING
Preparing for Release Planning
Set themes
Prepare the backlog
Divvy stories up
Understand the issues
Identify key dates
After a Release
Do Release Retrospective

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

SPRINT BACKLOG
Defined A single list of action items & tasks that answers How
will we do the work
Owned by Team
Rules Collectively planned by the whole team
Updated every day to reflect the teams latest
decisions
Best Estimated Manhour estimates on each task allow

Practices for creation of a burndown chart

MANAGING A SPRINT BACKLOG
Individuals sign-up for work on their own choosing
Estimated work remaining is updated daily
Any team member can add, delete or change the Sprint backlog
Work for the Sprint emerges
If work is unclear at the beginning of the Sprint, define a sprint backlog item with
a large amount of time and break it down later

A BURNDOWN CHART
Defined A chart visualizing how much work is remaining in a

timebox, thus answering how are we doing
Owned by Team
Rules Based on backlog data
Release Burndown for Product Backlog items
remaining in a Release
Sprint Burndown for Sprint Backlog items
remaining in a Sprint
Updated Often to reflect progress
Best Focus on trends, not values
Practices

HOW BURNDOWN WORKS
Backlog
------ ---------- --- -------- - #
--------- ---- ------- ---- ---- #
------ ---------- --- -------- - #
--------- ---- ------- ---- ---- #
A backlog is
measured by a
burndown
Burndown

SPRINT BURNDOWN
Task Hours Remaining
Days in Sprint

RELEASE BURNDOWN
Velocity
Story Units Remaining
Sprints in Release

SPRINT EXECUTION
A Sprint lasts between 1 week and 1 month
Scrum projects make progress in a series of Sprints
Product are designed, coded and tested during a Sprint
Sprints are a time-boxed effort of a constant length
A constant duration leads to a better rhythm
The Scrum team agrees on a Sprint Goal (a short statement on what the work will
be focused on during the sprint)

SPRINT PLANNING

SPRINT PLANNING
1 5 people x 2 wks x 6hrs/day: 300.0

Calculate the teams
Minus vacation: 224.0
total manhour capacity
Minus 20% Slack/ Risk Buffer: 179.2
for the upcoming Sprint
Commitment Cap: 179.2
2 Add the manhour

estimates for all the Sprint
Backlog tasks
3 Compare the 2
numbers to help the team
confirm the commitment
is reasonable
176
179 176
SPRINT PLANNING BEST PRACTICE
In the first half, the Product Owner briefs the team on the next priorities
Divide the from the Product Backlog, and the Team selects a set of items they deem
reasonable
Planning into In the second half, the team decomposes the commitments into the Sprint
2 Halves Backlog of action items and tasks needed to accomplish those
commitments
Many teams spend too much effort pre-assigning Sprint Backlog action
Defer Task items to Team Members, often causing the Sprint Planning to last many
hours too long.
Assignments Consider leaving the task assignments until later. This will allow Team
Members the opportunity to self-assign the tasks, generating more buy-in.
Defer The Sprint Backlog is an imperfect living work plan. 30-40% of the Sprint
Backlog tasks will change over the course of the Sprint.
Unknown Consider deferring the task definition for those things that are not fully
Details understood, and simply

SPRINT REVIEW
Purpose
To demonstrate work completed by the team during the Sprint.
Output
PO Approval or Rejection for each committed feature, story, or bug fix

PO feedback for completed work
Rules
The Product Owner must base his approval or rejection on the agreed-upon
acceptance criteria for each commitment.
The Team gives the demonstration, not the ScrumMaster.
The Team is held collectively accountable for failed commitments, not the
ScrumMaster

SPRINT RETROSPECTIVE

SPRINT RETROSPECTIVE - FORMATS
Suggested Topics
What went well, What could be better, What will we do about it
What should be continue doing, What should we start doing, What should we stop doing
Suggested Tools
Whiteboards, Flipcharts, Index Cards, Sticky Notes

SPRINT RETROSPECTIVE AN EXAMPLE
Team mind-map exercise to

understand relationships of project
issues

TECHNIQUES FOR RETROSPECTIVES
Post-it brainstorming
Dot voting
Keep / Start / Stop
Timeline
Team Radar
--------

YOUR FIRST AGILE PILOT PROJECT

MAKING AGILE ADOPTION SUCCESSFUL
Use a Physical Board
Start collecting and using statistics
Engage a coach / consultant
Action over talking
Give everyone training and start group-wide discussions
Enthuse, Pull, dont PUSH
Be clear on Why
Process and Technical , adopt technical side as well as process side
Get Product Management / Owner Flow to developers clear and clean
Structure changes Functional groups.

EXERCISE
Command and Control
Were working in pairs, look at your neighbour and introduce
yourself. For the exercise, one of you is to be the boss, the
other the worker. You pick.
The exercise is as follows: the boss tells the worker how to
make 60 steps through the room within a minute. He can do
this with the simple commands Go, Stop, Right, Left,
Faster, Slower.
And the worker does what the boss tells him to do. He also
counts the steps.
Dont hurt yourself! Nor others!

EXERCISE
Ok, remember what happened, and lets make a small change.
With the same teams as before, the workers can now decide
how to make the 60 steps, and the bosses remove any
obstacles the worker encounters. Do leave the walls in place!
This time you have 30 seconds

Questions?

EXERCISE BATCH VS. FLOW
Four volunteers please
Round 1
Each person flips all coins
When done with entire batch, pass to next person
Round 2
Each person flips one coin and pass to next person
Keep flipping and passing until done
Round 3
Each table creates their own rules to maximize coin flow/throughput in least
amount of time

ARE YOU AGILE?

PERFECTION IS A DIRECTION, NOT A PLACE

BE IN TOUCH
Email me : vasanthan.philip@gmail.com
Read my blog : vphilip.wordpress.com
Visit my website: www.vasanthanphilip.com
Call me : +91 90030 75368

TIMEBOXES
Three 1-hour sprints
10 minute planning
30 minute work
20 minute review & retrospective
Daily scrums every 10 minutes
ROLES Artefacts
Vice President
Product Owner Product Backlog of User
Team Stories
1 MS-Office Specialist Estimates in Story Points
1 Tester Burndown Chart
Everyone else exam developer
One of these must also be ScrumMaster

SCHEDULE
Time Item
2:30 SPRINT 1
2:40 End Planning, Begin Work
3:10 Review & Retrospective
3:30 SPRINT 2
4:30 SPRINT 3

SPEED BOAT
The speed boat provides

a fun format, collective
and committing in
identifying constrains,
obstacles, problems,
with products or with
projects and prioritize
actions.

LOST IN TRANSLATION


Agile Scrum

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Agile Scrum

Hochgeladen von

Copyright:

Verfügbare Formate

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

Analysis Design Develop Test Deploy

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

Waterfall calls for a fully formed idea up

4 Jeff Patton, all rights reserved, www.AgileProductDesign.com

A more iterative allows you to move

Do we have half 20% done

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

Conventional projects take too Lean (agile) methods link

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

Individuals and Interactions over processes and tools

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

Suited for Agile

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

Vision - Goals - Requirements - Features - User Stories

High Level Requirement represents what is to be designed

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

Techniques for Requirement Gathering

Prototyping Create screen prototypes for clear s/w requirements

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

User Story information is lightweight. It fits onto a single

When the story is selected for a Sprint, further details are

Acceptance criteria are added to the User Story, to confirm

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

When searching by a valid account number, the account is shown

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

Must have (or Minimum Usable Subset)

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

Allows us to change our mind when we have new information on a story

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

IDEAL DAYS Story Point

The elapsed time is much longer (2+ hours)

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

Can you distinguish a 1-point story from a 2?

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

An iterative approach to estimating Steps

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

This can be estimated by viewing previous sprints, assuming the team

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

What is Quality and how is it measured

COPYRIGHT MATERIAL - DISTRIBUTION IS PROHIBITED

Quality Goals for Applications