The document outlines Agile software development methodologies that emphasize iterative and incremental approaches to software creation, with a focus on collaboration, flexibility, and customer-centric practices. It introduces key concepts such as user stories, sprints, and roles within Scrum, while promoting principles like valuing individuals over processes and responding to change. Additionally, it highlights practices from Extreme Programming (XP) such as pair programming and continuous integration to enhance code quality and team collaboration.

4. From Wikipedia:
Its a group of software development methods based on
iterative and incremental development, where
requirements and solutions evolve through collaboration
between self-organizing, cross-functional teams........

5. 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.

8. Traditional “Waterfall” Approach
Detailed
Design
Detailed
Design
ConceptConcept
BuildBuild

9. Agile Process
Concept
Detailed
Design
Detailed
Design
Build Build
Detailed
Design
Detailed
Design
Build Build
Sprint
Review
Sprint
Review
Sprint
Review
Sprint
Review
Agile processes are based on a contionous process of Design it, Build
it, Test it, Ship it.

10. Being Agile – What's involved ?
Goal
Deliver high
value, high
quality
working s/w
quickly &
frequently
Ceremonies
Training
Release Planning
Iteration Planning
Daily Stan-up
Review / demo
Retrospective
Techniques
Iterations
User stories
Co-location
Task board
Burn chart
Planning Poker
Done-done-done
Pairing
Unit Test
Continous integration
Participate
Fundamentals
Short feedback
loops
Inspect &
adapt
Collaboration &
teamwork

11. Agile Myths
- No documentation
- No scope management
- No design
- 100% automation
- Only iterative development
- No architecture
- No strick deadline
(I can change my mind whenever I want to)

12. Scrum
&
Extreme Programming

13. Scrum Principles
✔
Time-boxes
✔
Cross-functional teams
✔
Open communications
– Within team
– With stakeholders
✔
Priorities set by Product Owner
✔
Demonstrable results
✔
Responsive to change

15. Scrum
Roles
- Scrum Master
- Scrum Team
- Product Owner
- Stakeholders
Sprint
Artifacts
- Product Backlog
- Sprint Backlog
- Burn down / up charts
Meetings
- Sprint Planning
- Daily Stand-up
- Sprint Review
- Sprint Retrospective

16. Roles
* Scrum Master
Not “command & control” project manager
Process coach and team facilitator
Remover of roadblocks
* Scrum Team
Individuals responsible for the Sprint results
Mix of skills representing multiple disciplines
Usually 6-8 individuals
* Product Owner
Individual responsible for product
Responsible for product profitability (ROI)
Adjusts feature list and priorities for each Sprint
Accepts or rejects work results
* Users & Stakeholders
Interested in results but not responsible for deliverables

17. The Sprint
* Time boxed effort
Usually 2 weeks to 1 month
Can be longer or shorter
* Defined workload
No changes once Sprint is begun
* Begins with Planning Meeting
* Ends with demonstrable Release

19. Product Backlog

20. Product Backlog
* All features and functions for final product
* May be subdivided into releases
* Prioritized by Product Owner
* Initial backlog is established and releases are defined prior to start
of Sprints
* Product backlog is reviewed and updated throughout the project
* Time must be allotted during Sprints to allow for this activity

21. Sprint Backlog
* Features and functions targeted for a single Sprint
- Frequently broken down into User Stories;
Especially if function is complex
* May include technical requirements or objectives
- e.g.; database design, UI standards, architecture
documentation

22. Burnup Charts

23. Sprint Planning
* Product Owner and Team
* Review of Product Backlog
* Product Owner provides definition and details of features and functions
* Negotiation of what will be in Sprint
* May identify new Product Backlog needs
* Results in Sprint Goals

24. Daily Stand-up

25. Daily Stand-up
* Standup 15 minute meeting
* Each team member answers 3 questions:
- What have you done since the last meeting?
- What will you do before the next meeting?
- What is preventing you from accomplishing your tasks?
* For benefit of other team members
* Not a “status report” to the ScrumMaster

26. Sprint Review
* Results of Sprint are demonstrated to Product Owner
* Owner accepts or rejects results
* Results are input to:
- Next Sprint Planning meeting
- Sprint Retrospective

27. Sprint Retrospective
* Meeting with Sprint Team
- May include Product Owner
* Process review and modification
* Lessons learned applied in following Sprints
* Techniques
– Mute Mapping
– Brainstorming

28. Mute – Mapping Technique

29. INDEX CARD 4”X6”
Three Parts (3 Cs)
 Card
 Conversation
 Confirmation
User Story
I N V E S T
The acronym INVEST stands for,
I – Independent, N – Negotiable, V – Valuable, E – Estimable, S – Small, T - Testable

30. User Story
 Provides a simple medium for
– Gathering basic information about stories,
– Recording high-level requirements,
– Developing work estimates, and
– Defining acceptance tests
 Acts as agreements between customers and team
members to discuss detail requirements during an
iteration

31. Example : User Story Card (Formal)
As a <role>,
I want <goal/desire>
so that <benefit>
As a
Who wants this piece of functionality
I want
What the user wants
So that
Why the user wants it
As an employee, I want to purchase a parking pass so that I can
park my car safely in the basement and save money.
Priority : 8
Estimate : 4

32. Theme and Epic
Theme is a set of related user
stories that may be combined
together and treated as a single
entity for either estimating or release
planning
Epics are large user stories with
lower priority. They are too big to
implement in a single iteration and
therefore they need to be
disaggregated into smaller user
stories at some point

33. Velocity
* Velocity is a measure of a team’s rate of
progress per iteration.
* It is calculated by summing the number
of story points assigned to each user
story that the team completed during
the iteration
Question :
The project team completes four stories in one iteration,
Story A – 5, Story B – 3, Story C – 7, Story D – 5. Calculate the Velocity?
Answer :
Summing up the story points assigned to each user story gives the velocity.
Hence velocity = 5+3+7+5 = 20

34. Prioritizing Requirements - MoSCoW

35. Agile Estimation
Agile Estimation

36. Estimating Size with Story Points
Story Points are the unit of
measurement for expressing the
overall size of a user story,
feature, or other piece of work.

37. Story Points
 The “bigness” of a task is influenced by,
• How hard it is (complexity)
• How much of it there is (effort involved)
• How risky it is
 Relative values are what is important:
• A login screen is a 2, A search feature is an 8.
 Estimate using the relative values
• Select the smallest story and estimate as 1 story point
• Select a medium-sized story and estimate it as 5 story points

38. 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 it’s discussed briefly
- Each estimator selects a card
that’s his or her estimate
- Cards are turned over so all can
see them
- Discuss differences (especially
outliers)
- Re-estimate until estimates
converge

39. Extreme programming

40. Extreme programming has been described as following practices
Fine scale feedback
- Pair programming
- Test-driven development
Continuous process
- Continuous integration
- Refactoring or design improvement
- Small releases
Shared understanding
- Coding standards
- Collective code ownership
- Simple design
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 before the bug is addressed
XP

41. Pair Programming
* Better Code
* Collective Code Ownership
* Mentoring
* Increased discipline
* Improved morale
* Team cohesion

42. Unit Testing
* Unit Testing reduces the level of bugs in production code.
* Unit Testing saves you development time.
* Automated tests can be run as frequently as required.
* Unit Testing makes it easier to change and refactor code.
* Unit Testing can improve the design of code especially with
TDD.
* Unit Tests are a form of documentation.
* Unit Testing inspires confidence!
* Unit Tests are a measure of completion.
* Unit Testing is FUN!

43. Coding Standards
• Code Integration
• Team Member Integration
• Maintenance
• Uniform Problem Solving
• Minimizes Communication
• Minimizes Performance Pitfalls
• Saves Money Due to Less Man Hours

44. CI
* Say goodbye to long and tense integrations
* Increase visibility which enables greater communication
* Catch issues fast and nip them in the bud
* Spend less time debugging and more time adding features
* Proceed in the confidence you’re building on a solid foundation
* Stop waiting to find out if your code’s going to work
* Reduce integration problems allowing you to deliver software
more rapidly

45. CI – Reminder / Rules
* Check in frequently
* Don’t check in broken code
* Don’t check in untested code
* Don’t check in when the build is broken
* Don’t go home after checking in until the system builds
-----
* Maintain a Single Source Repository
* Make Your Build Self-Testable
* Every Commit Should Build the Mainline on an Integration Machine
* Keep the Build Fast
* Everyone can see what's happening
* Automate Deployment
-----
* Detect integration errors as quickly as possible
* Assumes a high degree of tests
* Always have a deployable build
* Generate metrics to guide project management
* Continuous Integration is Vital for Agile Development

46. Q & A