■ Agile Development

1
The Manifesto for
Agile Software Development
“We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
•Individuals and interactions over processes and
tools
•Working software over comprehensive
documentation
•Customer collaboration over contract
negotiation
•Responding to change over following a plan
That is, while there is value in the items on the
right, we value the items on the left more.”
Kent Beck et al

2
 What is “Agility”?
■ Effective (rapid and adaptive) response to change (team members, new
technology, requirements)
■ Effective communication in structure and attitudes among all team
members, technological and business people, software engineers and
managers。
■ Drawing the customer into the team. Eliminate “us and them” attitude.
Planning in an uncertain world has its limits and plan must be flexible.
■ Organizing a team so that it is in control of the work performed
■ Eliminate all but the most essential work products and keep them lean.
■ Emphasize an incremental delivery strategy as opposed to intermediate
products that gets working software to the customer as rapidly as feasible.

3
 What is “Agility”?

Yielding …
■ Rapid, incremental delivery of software
■ The development guidelines stress delivery over
analysis and design although these activates are
not discouraged, and active and continuous
communication between developers and
customers.

4
Why and What Steps are“Agility”
important?

■ Why? The modern business environment is fast-paced

and ever-changing. It represents a reasonable alternative
to conventional software engineering for certain classes
of software projects. It has been demonstrated to deliver
successful systems quickly.
■ What? May be termed as “software engineering lite” The
basic activities- communication, planning, modeling,
construction and deployment remain. But they morph
into a minimal task set that push the team toward
construction and delivery sooner.
■ The only really important work product is an operational
“software increment” that is delivered.

5
Agility and the Cost of Change
■ Conventional wisdom is that the cost of change increases nonlinearly
as a project progresses. It is relatively easy to accommodate a change
when a team is gathering requirements early in a project. If there are
any changes, the costs of doing this work are minimal. But if the
middle of validation testing, a stakeholder is requesting a major
functional change. Then the change requires a modification to the
architectural design, construction of new components, changes to
other existing components, new testing and so on. Costs escalate
quickly.

■ A well-designed agile process may “flatten” the cost of change curve

by coupling incremental delivery with agile practices such as
continuous unit testing and pair programming. Thus team can
accommodate changes late in the software project without dramatic
cost and time impact.

6
Agility and the Cost of Change

7
 An Agile Process
■ Is driven by customer descriptions of what is required
(scenarios). Some assumptions:
■ Recognizes that plans are short-lived (some requirements will persist, some
will change. Customer priorities will change)
■ Develops software iteratively with a heavy emphasis on construction
activities (design and construction are interleaved, hard to say how much design is
necessary before construction. Design models are proven as they are created. )
■ Analysis, design, construction and testing are not predictable.
■ Thus has to Adapt as changes occur due to unpredictability
■ Delivers multiple ‘software increments’, deliver an operational
prototype or portion of an OS to collect customer feedback
for adaption.

8
Agility Principles - I
1. Our highest priority is to satisfy the customer through early
and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development.
Agile processes harness change for the customer's competitive
advantage.
3. Deliver working software frequently, from a couple of weeks to
a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily
throughout the project.
5. Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the
job done.
6. The most efficient and effective method of conveying
information to and within a development team is face–to–face
conversation.

9
Agility Principles - II
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The
sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good
design enhances agility.
10. Simplicity – the art of maximizing the amount of work
not done – is essential.
11. The best architectures, requirements, and designs
emerge from self–organizing teams.
12. At regular intervals, the team reflects on how to become
more effective, then tunes and adjusts its behavior
accordingly.

10
Problems with agile
methods
■ It can be difficult to keep the interest of
customers who are involved in the process.
■ Team members may be unsuited to the intense
involvement that characterises agile methods.
■ Prioritising changes can be difficult where
there are multiple stakeholders.
■ Maintaining simplicity requires extra work.
■ Contracts may be a problem as with other
approaches to iterative development.
 Human Factors

■ the process molds to the needs of the people and team, not the
other way around
■ key traits must exist among the people on an agile team and
the team itself:
■ Competence. ( talent, skills, knowledge)
■ Common focus. ( deliver a working software increment )
■ Collaboration. ( peers and stakeholders)
■ Decision-making ability. ( freedom to control its own destiny)
■ Fuzzy problem-solving ability.(ambiguity and constant changes, today
problem may not be tomorrow’s problem)
■ Mutual trust and respect.
■ Self-organization. ( themselves for the work done, process for its local
environment, the work schedule)
12
eXtreme Programming
Overview
 What’s wrong with software
today?
■ Software development is risky and difficult to manage
■ Customers are often dissatisfied with the development
process
■ Programmers are also dissatisfied
 One Alternative: Agile
Development Methodologies
■ XP = eXtreme Programming
■ It does not encourage blind hacking. It is a systematic methodology.
■ Developed by Kent Beck
■ XP is “a light-weight methodology for small to medium-sized teams
developing software in the face of vague or rapidly changing
requirements.”
■ Alternative to “heavy-weight” software development models
(which tend to avoid change and customers)
■ "Extreme Programming turns the conventional software process
sideways. Rather than planning, analyzing, and designing for the
far-flung future, XP programmers do all of these activities a little
at a time throughout development.”
-- IEEE Computer , October 1999
 Traditional Processes are
Change
‘Heavy’
Cost of

Requirements Design Implementation Testing Maintenance

 Boehm’s Curve
■ To accomplish this:
■ We need lots of up front planning, resulting in
“heavy” methodologies
■ Every bug caught early saves money, since models
are easier to modify than code
■ Large investments are made in up front analysis and
design models, because the of the cost of late error
discovery
■ This leads to a waterfall mentality with BDUF (Big
Design Up Front)
■ Proponents of XP argue that logic is based on
development in the 1970’s and 1980’s
 What’s Changed?
■ Computing power has increased astronomically
■ New tools have dramatically reduced the
compile/test cycle
■ Used properly, OO languages make software much
easier to change
■ The cost curve is significantly flattened, i.e. costs
don’t increase dramatically with time
■ Up front modeling becomes a liability – some
speculative work will certainly be wrong, especially
in a business environment
 Why XP Helps
■ Extreme Programming is a “light” process that creates and
then exploits a flattened cost curve
■ XP is people-oriented rather than process oriented,
explicitly trying to work with human nature rather than
against it
■ XP Practices flatten the cost of change curve.
Change
XP Cost of Change Curve
Cost of

XP cost
of
change
curve
 Embrace change
■ In traditional software life cycle models, the cost of
changing a program rises exponentially over time
■ A key assumption of XP is that the cost of changing a
program can be hold mostly constant over time
■ Hence XP is a lightweight (agile) process:
■ Instead of lots of documentation nailing down what customer
wants up front, XP emphasizes plenty of feedback
■ Embrace change: iterate often, design and redesign, code and
test frequently, keep the customer involved
■ Deliver software to the customer in short (2 week) iterations
■ Eliminate defects early, thus reducing costs
 Why does XP Help?
■ “Software development is too hard to spend time on things
that don't matter. So, what really matters? Listening,
Testing, Coding, and Designing.” - Kent Beck, “father” of
Extreme Programming
■ Promotes incremental development with minimal up-front
design
■ Results in a “pay as you go” process, rather than a high
up-front investment
■ Delivers highest business value first
■ Provides the option to cut and run through frequent
releases that are thoroughly tested
 More on XP
■ XP tends to use small teams, thus reducing communication
costs.
■ XP puts Customers and Programmers in one place.
■ XP prefers index cards to expensive round-trip UML
diagramming environments
■ XP's practices work together in synergy, to get a team
moving as quickly as possible to deliver value the customer
wants
 Successes in industry
■ Chrysler Comprehensive Compensation system
■ After finding significant, initial development problems, Beck and
Jeffries restarted this development using XP principles
■ The payroll system pays some 10,000 monthly-paid employees
and has 2,000 classes and 30,000 methods, went into
production almost on schedule, and is still operational today
(Anderson 1998)
■ Ford Motor Company VCAPS system
■ Spent four unsuccessful years trying to build the Vehicle Cost
and Profit System using traditional waterfall methodology
■ XP developers successfully implemented that system in less
than a year using Extreme Programming (Beck 2000).
XP Process
■ Planning
■ User stories are written
■ Release planning creates the schedule.
■ Make frequent small releases.
■ The Project Velocity is measured.
■ The project is divided into iterations.
■ Iteration planning starts each iteration.
■ Move people around.
■ A stand-up meeting starts each day.
XP Process
■ Designing
■ Simplicity.
■ Choose a system metaphor.
■ Use index cards for design sessions.
■ Create spike solutions to reduce risk.
■ No functionality is added early.
■ Refactor whenever and wherever possible.
XP Process
■ Coding
■ The customer is always available.
■ Code must be written to agreed standards.
■ Code the unit test first.
■ All production code is pair programmed.
■ Only one pair integrates code at a time.
■ Integrate often.
■ Use collective code ownership.
■ Leave optimization until the end.
■ No overtime.
XP Process
■ Testing
■ All code must have unit tests.
■ All code must pass all unit tests before it can be
released.
■ When a bug is found tests are created.
■ Acceptance tests are run often and the score is
published.
Four Core Values of XP
■ Communication
■ Simplicity
■ Feedback
■ Courage
 Communication
■ What does lack of communication do to
projects?
■ XP emphasizes value of communication in many
of its practices:
■ On-site customer, user stories, pair programming,
collective ownership (popular with open source
developers), daily standup meetings, etc.
■ XP employs a coach whose job is noticing when
people aren’t communicating and reintroduce
them
 Simplicity
■ ''Do the simplest thing that could possibly work''
(DTSTTCPW) principle
■ Elsewhere known as KISS (Keep It Simple, Stupid).
■ A coach may say DTSTTCPW when he sees an XP
developer doing something needlessly complicated
■ YAGNI principle (''You ain’t gonna need it‘’)
While DTSTTCPW focuses on keeping the
implementation of a feature simple, YAGNI focuses on not
implementing the feature at all until it is actually needed.
■ Refactoring: DTSTTCPW works because XP relies on
continuous refactoring. You start with the simplest solution
and, as needs evolve, you improve the design to keep it
simple
 Feedback
■ Feedback at different time scales
■ Unit tests tell programmers status of the system
■ When customers write new user stories, programmers
estimate time required to deliver changes
■ Programmers produce new releases every
2-3 weeks for customers to review
Courage

■ The courage to communicate and accept feedback

■ The courage to throw code away (prototypes)
■ The courage to refactor the architecture of a system
 Twelve XP Practices
■ The Planning Game ■ Pair Programming
■ Small Releases ■ Collective Ownership
■ Metaphor ■ Continuous Integration
■ Simple Design ■ 40-Hours a Week
■ Test-driven development ■ On-Site Customer
■ Refactoring ■ Coding Standards
 The Planning Game
■ Customer comes up with a list of desired features for the
system
■ How is this different from the usual requirements gathering?
■ Each feature is written out as a user story
■ Describes in broad strokes what the feature requires
■ Typically written in 2-3 sentences on index cards
■ Developers estimate how much effort each story will take,
and how much effort the team can produce in a given time
interval (iteration)
Format of User Stories:
"As a [type of user], I want [an action], so that [a benefit]“
Search: "As a visitor, I want to search for products by keyword,
so I can find items quickly".
Security: "As an admin, I want to disable a user, so I can prevent
unauthorized access".
 User Stories
■ Each Story is written by the customer and is placed on index
card
■ The customer assigns a value (priority) to the story
■ Members of XP team then assess each story and assigns cost
(weeks)
■ Customers and developers work together to decide how to
group stories in to the next release
■ All stories will be implemented immediately (within few weeks)
■ The stories with highest value will be moved up in the schedule and
implemented first
■ The riskiest stories will be moved up in the schedule and implemented first

These slides are designed to accompany Software Engineering: A Practitioner’s Approach,

7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 36
 User Stories
■ Drive the creation of the acceptance tests:
■ Must be one or more tests to verify that a story has been
properly implemented
■ Different than Requirements:
■ Should only provide enough detail to make a reasonably
low risk estimate of how long the story will take to
implement.
■ Different than Use Cases:
■ Written by the Customer, not the Programmers, using the
Customer’s terminology
■ More “friendly” than formal Use Cases
User Story Examples
 User Stories
Project Velocity : Is the number of customer stories implemented
during the first release

■Project velocity can then be used to

■ Help estimate delivery dates and schedule for subsequent release and

■ Determine whether an overcommitment has been made for all stories

across the entire development project
If it occurs, the content of releases is modified or end delivery dates are
changed

■As development work proceeds, the customer can add stories,

change the value of an existing story, split stories, or eliminate
them. The XP team then reconsiders all remaining releases and
modifies its plan accordingly
 Acceptance criteria
Acceptance criteria are the specific, actionable conditions
that must be met for the user story to be considered "Done,"
often using a checklist or "Given-When-Then" format.

Example 1: E-commerce Login

User Story: As a registered user, I want to log into my account
so that I can access my personal dashboard.
Acceptance Criteria:
■ System allows login with valid email and password.
■ Error message "Invalid email or password" appears on incorrect input.
■ System redirects user to dashboard upon success.
■ Account locks after 5 consecutive failed attempts.
40
Example 2: Content Management (Scheduling)
User Story: As a content creator, I want to schedule posts in advance
so that I can maintain a consistent publishing schedule.

Acceptance Criteria:
•User can select date/time for post publishing.
•Post is automatically published at the exact scheduled time.
•User can edit or cancel a scheduled post before it goes live

Example 3: Search Functionality

User Story: As a customer, I want to search for products by category
so I can easily find what I'm looking for.

Acceptance Criteria:
•Search field is in the header, on the left side.
•Field contains a "Search by city, district" placeholder.
•Search begins when the user clicks the "Search" button
41
Example 4: Form Submission (Behavior Driven Development - BDD)
User Story: As a new user, I want to sign up for an account so I
can access premium content.

Acceptance Criteria:
■ Given I am on the signup page, When I fill in all valid required fields
and click submit, Then I am redirected to the welcome page.
■ Given I am on the signup page, When I submit with an invalid email
format, Then I see an error message indicating invalid input.

42
 Design

■ No tedious UML (KIS principle)

■ Use CRC cards
(class-responsibility-collaboration)
■ Web example:
[Link]
org/example/[Link]
 Small and simple
■ Small releases
■ Start with the smallest useful feature set
■ Release early and often, adding a few features each
time
■ Releases can be date driven or user story driven
■ Simple design
■ Always use the simplest possible design that gets the
job done
■ The requirements will change tomorrow, so only do
what's needed to meet today's requirements
(remember, YAGNI)
Extreme Programming (XP)

45
 Pair programming
■ Two programmers work together
at one machine
■ Driver enters code, while
navigator critiques it
■ Periodically switch roles

• Research results:
– Pair programming increases productivity
– Higher quality code (15% fewer defects) in about half the time
(58%)
– Williams, L., Kessler, R., Cunningham, W., & Jeffries, R.
Strengthening the case for pair programming. IEEE Software,
17(3), July/August 2000
– Requires proximity in lab or work environment
 More XP practices
■ Refactoring
■ Refactor out any duplicate code generated in a coding
session
■ You can do this with confidence that you didn't break
anything because you have the tests
■ Collective code ownership
■ No single person "owns" a module
■ Any developer can work on any part of the code base at any
time
■ Continuous integration
■ All changes are integrated into the code base at least daily
■ Tests have to run 100% both before and after integration
 More practices
■ 40-hour work week
■ Programmers go home on time
■ “fresh and eager every morning, and tired and satisfied every
night”
■ In crunch mode, up to one week of overtime is allowed
■ More than that and there’s something wrong with the process
■ On-site customer
■ Development team has continuous access to a real live
customer, that is, someone who will actually be using the
system
■ Coding standards
■ Everyone codes to the same standards
■ Ideally, you shouldn't be able to tell by looking at it who on
the team has touched a specific piece of code
 13th XP practice: Daily standup meeting
■ Goal: Identify items to be accomplished for the day
and raise issues

• Everyone attends,
including the customer
• Not a discussion forum
• Take discussions offline
• Everyone gets to speak
• 15 minutes
 Industrial Extreme
Programming (IXP)

* 50
 Industrial Extreme
Programming(IXP)
■ proposed by Kent Beck
■ Defined as
“IXP is an organic evolution of XP. It is imbued with
XP’s minimalist, customer-centric, test-driven spirit.”
■ refines XP and targets the agile process
specifically for use within large organizations
■ Differs from original XP in
■ Its inclusion of management
■ Its expanded role for customers
■ Its upgraded technical practices

* 51
 IXP Practices
■ Readiness Assessment
■ Project Community
■ Project Chartering
■ Test-driven Management
■ Retrospectives
■ Continuous Learning

* 52
 IXP Practices
■ Readiness Assessment
■ Project Community
■ Project Chartering
■ Test-driven Management
■ Retrospectives
■ Continuous Learning

* 53
 Readiness Assessment
■ It ascertains whether
■ an appropriate development environment exists to
support
■ the team will be populated by the proper set of
stakeholders
■ the organization has a distinct quality program and
supports continuous improvement
■ the organizational culture will support the new
values of an agile team
■ the broader project community will be populated
appropriately

* 54
 IXP Practices
■ Readiness Assessment
■ Project Community
■ Project Chartering
■ Test-driven Management
■ Retrospectives
■ Continuous Learning

* 55
 Project Community
■ “team” should be morph into that of “community”
■ A community may have a technologist and
customers as well as stakeholders
■ The community members and their roles should be
explicitly defined
■ Mechanism for communication and coordination
between community members should be
established

* 56
 IXP Practices
■ Readiness Assessment
■ Project Community
■ Project Chartering
■ Test-driven Management
■ Retrospectives
■ Continuous Learning

* 57
 Project Chartering
■ assesses the project to determine whether an
appropriate business justification for the project
exists
■ examines the context of the project to determine
how it complements, extends, or replaces existing
systems or processes
■ Project Chartering helps people answer questions
like
■ Is the idea for the project worthwhile?
■ How does the project further the organization's
vision/mission?
■ How would we know if the project is a success?
■ Who is part of the project's Project Community?
* 58
 IXP Practices
■ Readiness Assessment
■ Project Community
■ Project Chartering
■ Test-driven Management
■ Retrospectives
■ Continuous Learning

* 59
 Test-driven Management
■ used to assess the state of the project and progress
■ establishes a series of measurable “destinations” and
then defines mechanisms for determining whether or not
these destinations have been reached

* 60
 IXP Practices
■ Readiness Assessment
■ Project Community
■ Project Chartering
■ Test-driven Management
■ Retrospectives
■ Continuous Learning

* 61
 Retrospectives: Self-reflection
■ is a technical review to examine issues, events, and
lessons-learned across a software increment and/or
the entire software release

■ is a rigorous, future-focused process for capturing

the wisdom of lessons learned, best practices, and
multiple perspectives for continuous improvement of
software development and work environment

* 62
 IXP Practices
■ Readiness Assessment
■ Project Community
■ Project Chartering
■ Test-driven Management
■ Retrospectives
■ Continuous Learning

* 63
 Continuous Learning
■ used for continuous process improvement
■ XP team members are encouraged to learn new
methods and techniques for higher-quality product

* 64
 References
■ Roger S. Pressman, “Software Engineering, A Practitioner’s
Approach”, 7th edition
■ [Link]

* 65
 Scrum in 100 words
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.
 History of Scrum
■ 1995:
■ analysis of common software development processes 🡪 not suitable for
empirical, unpredictable and non-repeatable processes
■ 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 conference

■ 2001:
publication “Agile Software Development with Scrum” by
Ken Schwaber & Mike Beedle

Successful appliance of Scrum in over 50 companies

Founders are members in the Agile Alliance
 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”
How Scrum Works?
 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
Sequential vs. Overlapping Dev.

Requirement
Design Code Test
s
 No changes during the
C
sprint
h
a
n
g
e

Inputs Sprint Tested Code

■ Plan sprint durations around how long you can

commit to keeping change out of the sprint
 Scrum Framework
■ Roles : Product Owner, ScrumMaster, Team
■ Ceremonies : Sprint Planning, Sprint Review,
Sprint Retrospective, & Daily Scrum Meeting
■ Artifacts : Product Backlog, Sprint Backlog,
and Burndown Chart
 Product Owner
■ Define the features of the product
■ Decide on release date and content
■ Be responsible for the profitability of the
product (ROI) (Return On Investments)
■ Prioritize features according to market value
■ Adjust features and priority every iteration, as
needed
■ Accept or reject work results.
 The Scrum Master
■ Represents management to the project
■ Responsible for enacting Scrum values and
practices
■ Removes impediments
■ Ensure that the team is fully functional and
productive
■ Enable close cooperation across all roles and
functions
■ Shield the team from external interferences
 Scrum Team
■ Typically 5-10 people
■ Cross-functional
■ QA, Programmers, UI Designers, etc.
■ Members should be full-time
■ May be exceptions (e.g., System Admin, etc.)
■ Teams are self-organizing
■ What to do if a team self-organizes someone off the
team??
■ Ideally, no titles but rarely a possibility
■ Membership can change only between sprints
 Ceremonies
■ Sprint Planning Meeting
■ Sprint
■ Daily Scrum
■ Sprint Review Meeting
 Spring Planning Meeting

er

t
m

en
wn

s
a

er

em
Te
tO

om

ag
m
uc

st
ru

an
Cu
od

Sc

M
Product Backlog Pr

Team Capabilities
Sprint Goal
Business Sprint Planning
Conditions
Meeting Sprint Backlog
Technology

Current Product
 Parts of Sprint Planning
Meeting
■ 1st Part:
■ Creating Product Backlog
■ Determining the Sprint Goal.
■ Participants: Product Owner, Scrum Master, Scrum
Team
■ 2nd Part:
■ Participants: Scrum Master, Scrum Team
■ Creating Sprint Backlog
Pre-Project/Kickoff Meeting
■ A special form of Sprint Planning Meeting
■ Meeting before the begin of the Project
 Sprint
■ A month-long iteration, during which is
incremented a product functionality
■ NO outside influence can interfere with the
Scrum team during the Sprint
■ Each Sprint begins with the Daily Scrum
Meeting
 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?
■ Chickens and pigs are invited
■ Help avoid other unnecessary meetings
■ Only pigs can talk
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
 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
 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
 Sprint Retrospective
Meeting
■ Scrum Team only
■ Feedback meeting
■ Three questions
■ Start
■ Stop
■ Continue
■ Don’t skip for the first 5-6 sprints!!!
 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.
 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
PM
Sample Product Backlog
From Sprint Goal to Sprint Backlog

■ 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
■ Sprint Backlog is created
 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
 Sprint Backlog
■ A subset of Product Backlog Items, which
define the work for a Sprint
■ Is created ONLY by Team members
■ Each Item has it’s own status
■ Should be updated every day
Sprint Backlog
■ No more than 300 tasks in the list
■ If a task requires more than 16 hours, it should
be broken down
■ Team can add or subtract items from the list.
Product Owner is not allowed to do it
Sample Sprint Backlog
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
 Information Radiator
"Two characteristics are key to a good
information radiator. The first is that the
information changes over time. This makes it
worth a person's while to look at the display...
The other characteristic is that it takes very
little energy to view the display."
Sprint Burndown Chart
 Release Burndown 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
 Product Burndown Chart
■ Is a “big picture” view of project’s progress (all
the releases)
 Scalability of Scrum
■ A typical Scrum team is 6-10 people
■ Jeff Sutherland - up to over 800 people
■ "Scrum of Scrums" or what called
"Meta-Scrum“
■ Frequency of meetings is based on the degree
of coupling between packets
Scalability of Scrum
Scalability of Scrum
 Pros/Cons
▪ Advantages
▪ Completely developed ▪ Drawbacks
and tested features in ▪ “Undisciplined hacking”
short iterations (no written
▪ Simplicity of the documentation)
process ▪ Violation of
▪ Clearly defined rules responsibility
▪ Increasing productivity ▪ Current mainly carried
▪ Self-organizing by the inventors
▪ each team member
carries a lot of
responsibility
▪ Improved
communication
▪ Combination with
Extreme Programming
Is this Pair Programming?
 Pair Programming

We help each other succeed. This practice comes from XP.

Pair Programming
When you pair, one person codes—the driver. The other
person is the navigator, whose job is to think
The driver focuses on writing syntactically correct code.
The navigator sometimes works on understanding how
the current work fits in the over-all design and
sometimes thinks of the next task.
Since we are trying to do simple design things are evolving
the developers require a lot of discipline and pair
programming enforces this.

This form of development is very resilient to external

interruptions.

Above all it allows and forces individuals to collaborate and

share knowledge.
Pair Programming-
Challenges
Pair programming can be uncomfortable in the
beginning, especially if you are not used to
collaborating.

Comfort needs repeating.

Communication issues.

Organizational buy-in - Isn’t it more expensive?

Continuous Integration
The ultimate goal of continuous integration is to be able to deploy all
code.

Although you won’t release in the middle of a sprint, the point is to be

technologically ready, even if you are not functionally.

With Continuous integration, you are integrating in short cycle and

thus have smaller changes to deal with as you integrate.

Continuous integration does not make sense unless it’s automated,

has a short turn around time (fast builds), and everyone owns the
concept of Green Builds.

You need tests to fail or pass a build. Tests are the backbone that give
you a green or a red light to take a snapshot of your build.
Continuous Integration -
Advantages
■ Reduces to lengthy process
■ Enables the Small Releases practice
Continuous Integration –
Disadvantages
■ The one day limit is not always practical
■ Reduces the importance of a well-thought-out
architecture
 Test Driven Development

We produce well-designed, well-tested, and well-factored

code in small, verifiable steps.
Test Driven Development
Test-driven development, or TDD, is a rapid cycle of
testing, coding, and refactoring

Why do this: Programming is demanding. It requires

perfection and consistency for months.

TDD cranks up the feedback on the execution of

your code. Every few minutes TDD verifies that the
code does what you think it should do.

If you do this correctly and in incremental steps

you can reduce the defects in your system.
Test Driven Development
Benefits
Makes finding mistakes easy.

Think of double-entry bookkeeping. You express

your intent twice, once with a testand another
with production code.

All these tests are checked in and become part of

your continuous integration.
Test Driven Development-
Challenges
It will increase your effort. But should reduce
effort at the end of delivery cycle.

If you have legacy code extra effort and time is

required to place hooks for TDD.

The basic steps of TDD are easy to learn, but the

mindset takes a while to master.

This is a skill and requires continuous practice to

get better.
Refactoring
■ Refactoring is the process of code
improvement where code is reorganised and
rewritten to make it more efficient, easier to
understand, etc.
■ Refactoring is required because frequent
releases mean that code is developed
incrementally and therefore tends to become
messy.
■ Refactoring should not change the
functionality of the system.
■ Automated testing simplifies refactoring as you
can see if the changed code still runs the tests
successfully.
Refactoring – Advantages
■ Prompts developers to proactively improve the
product as a whole
■ Increases developer knowledge of the system
Refactoring – Disadvantages
■ Not everyone is capable of refactoring
■ Refactoring may not always be appropriate
■ Would upfront design eliminate refactoring?
 Two views of agile testing
eXtreme Testing Exploratory Testing
■ Automated unit testing ■ Manual testing by professional
■ Developers write tests skilled testers
■ Test first development ■ Freedom, flexibility and fun for
testers
■ Daily builds with unit tests always
100% pass ■ Controllability, reliability and high
quality for managers
■ Functional testing
■ Optimized to find bugs
■ Customer-owned
■ Continually adjusting plans,
■ Comprehensive
re-focusing on the most
■ Repeatable promising risk areas
■ Automatic ■ Following hunches
■ Timely ■ Minimizing time spent on
■ Public documentation

Focus on automated Focus on manual

verification – enabling agile validation – making
software development testing activities agile
 Definitions of Exploratory
Testing
❑ To the extent that the next test we do is influenced by the result of
the last test we did, we are doing exploratory testing. James Bach,
2001
❑ Exploratory testing involves simultaneously learning, planning,
running tests, troubleshooting and reporting results. Cem Kaner, 2001

■ In scripted testing, tests are first ■ In exploratory testing, tests are

designed and recorded. Then designed and executed at the
they may be executed at some same time, and they often are not
later time or by a different tester. recorded.

■ You build a mental model of the

product while you test it. This
model includes what the product
is and how it behaves, and how
it’s supposed to behave.