1) Commercial software, in-house development, contract development, and fixed-price projects. 2) Financial applications, ISO 9001-certified applications, embedded systems, and 24x7 systems with high uptime requirements. 3) Video game development, life-critical systems, satellite-control software, websites, handheld software, mobile phones, and some of the largest applications in use.

1. What are Spikes

2. Spike Solutions
• Create spike solutions to figure out answers to tough
technical or design problems.
• A spike solution is a very simple program to explore
potential solutions. Build a system which only
addresses the problem under examination and ignore
all other concerns.
• The goal is reducing the risk of a technical problem or
increase the reliability of a user story's estimate.

3. Big Design Up Front (BDUF)

4. What are the purpose of User
Stories…

5. Purpose
• User Stories are used to create time estimates for the release planning
meeting.
• They are also used instead of a large requirements document.
• User Stories also drive the creation of the acceptance tests.

6. What is Planning Feedback Loop

7. 7

8. The XP Roadmap

9. XP practices—a road map
(from www.extremeprogramming.org)
9

10. XP emphasizes iteration

11. XP emphasizes iteration
11

12. XP emphasizes communication

13. Communication is important
13

14. Test-driven development

15. Test-driven development
15

16. References/Links
Books
• Kent Beck, "Extreme Programming Explained," Addison-Wesley,
2000.
• Giancarlo Succi, Michelle Marchesi, "Extreme Programming
Examined," Addison-Wesley, 2001.
Websites
• http://www.extremeprogramming.org
• http://www.xprogramming.com
• http://www.jera.com/techinfo/xpfaq.html
• http://www.c2.com/cgi/wiki?ExtremeProgrammingRoadmap
• http://ootips.org/xp.html
• http://pairprogramming.com/

17. Effort Distribution in a XP project…

18. Effort Distribution: Project Management

19. Effort Distribution: Planning

20. Effort Distribution: Coding

21. Effort Distribution: Project Meetings

22. SCRUM

23. SCRUM
• SCRUM is an
• Agile Project Management Methodology
• Characteristics of an ‘Agile’ methodology are:
• ADAPTIVE, not PREDICTIVE
• LIGHTWEIGHT, not HEAVYWEIGHT
• DESCRIPTIVE, not PRESCRIPTIVE

24. SCRUM
• Scrum is a lightweight process that can manage and
control software and product development.
– It is a Project management process.
• However, instead of promoting the traditional analysis,
design, code, test, deploy "waterfall" approach, Scrum
embraces iterative and incremental practices.

25. SCRUM
• Similarly, instead of being "artifact-driven", whereby
large requirements documents, analysis specifications,
design documents, etc. are created, Scrum requires
very few artifacts.
• It concentrates on what’s important: managing a
project or writing software that produces business
value.

26. SCRUM
SCRUM has the following ELEMENTS :
• A project team called a SCRUM Team
• A Product Backlog of all known Requirements
• A Sprint Backlog of requirements being worked on
• A period of work referred to as a Sprint
• Daily Stand-up Meetings with the SCRUM Team
• A Burndown Chart to track progress of the Sprint
• An Incremental Delivery at the end of each sprint

27. A Model of SCRUM
Burndown Chart
Daily
SCRUM
Product Backlog
Sprint
Sprint Backlog Incremental Delivery
2 - 4 Weeks

28. The SCRUM Team
• Is all the people who will COMMITTED to the delivery of the
backlogs
• One role is ‘SCRUM Master’ who is in practice the PM
• Is staffed by PMs, BAs, Developers, Testers, Support – i.e. ALL
the typical project staff

29. Product Backlog
• Contains all the currently known requirements for a
product
• Is managed by the Product Owner and can change as
needed

30. Sprint Backlog
• Contains the set of prioritised Product Backlog items
that are currently being worked on
• Are not to be changed during the Sprint

31. Sprint
• Is a fixed period of development and testing
• Results in an incremental delivery of usable product
• Usually lasts 2 to 4 weeks

32. Daily SCRUM Meeting
• Brief ‘Stand-up’ meeting each morning with SCRUM
Team only
• What value did you add yesterday?
• What value will you add today?
• What will stop you making progress?

33. Burndown chart
• Charts delivery of the Sprint Backlog against Sprint
Duration.
• Simple, at-a-glance view of progress showing velocity and
traction
• Easy to keep updated

34. Incremental Delivery
• Output of the Sprint
• Working functionality that can be deployed
• Delivered every 2 to 4 weeks, tested and working

35. Scrum’s three questions

36. What is Scrum Roles?
• Product Owner
• Possibly a Product Manager or Project Sponsor
• Marketing
• Internal Customer
• etc.
• ScrumMaster
• Represents management to the project
• Typically filled by a Project Manager or Team Leader
• Responsible for enacting Scrum values and practices
• Main job is to remove impediments and remove any politics
• Project Team
• 5-10 members
• Cross-functional: QA, Programmers, UI Designers, etc.
36

37. Scrum Process Flow

39. Process Comparison

40. The product owner plans the
product in layers
© 2006-2007 Jeff Patton, 40
All rights reserved,
www.agileproductdesign.

41. The product owner plans the product in
layers
Product Release
or Project How can we release value
incrementally?
What business
What subset of business
objectives will the
objectives will each release
product fulfill?
achieve?
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 the
move us toward release story serve?
objectives? How will it specifically look and
Iteration Plan behave?
How will I determine if it’s completed?
Story Details
Acceptance Tests
41

42. The Planning Onion can grow to include
product portfolios and business strategy
Product or Release
Product
or Project
Project How can we release value
incrementally?
What business
Release
What subset of business
objectives will the
objectives will each release
product fulfill?
achieve?
What user constituencies will
Iteration the release serve?
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 the
move us toward release story serve?
objectives? How will it specifically look and
Iteration Plan behave?
How will I determine if it’s completed?
Story Details
Acceptance Tests
42

43. The Planning Onion can grow to include
product portfolios and business strategy
Product or
Project
Release
Iteration
Story
43

44. The Planning Onion can grow to include
product portfolios and business strategy
Business
Strategy
Product
Portfolio
Product or
Project
Release
Iteration
Story
44

45. Design and Coded Features Pass Back and
Forth Between Tracks
Sprint 0 Sprint 1 Sprint 2 Sprint 3
• planning • gather user input for • gather user input for • gather user input for
• data gathering iteration 3 features iteration 4 features iteration 5 features
• design for iteration • design iteration 2 • design iteration 3 • design iteration 4
1 features – high features features features
technical • support iteration 1 • support iteration 2 • support iteration 3
requirements, low development development development
user requirements • validate iteration 1 • validate iteration 2
features features
support dev
support dev
fea gs y t
fea
+ abil
es
tu fou esti
bu it
us
tu
ur
re
re
de nd i g
at
sig n
fe
d
es
n
ed
ign
d
n
• development implement iteration 1 co implement iteration 2 implement iteration 3
environment setup features features features
• architectural fix iteration 1 bugs if fix iteration 2 bugs if
“spikes” any any
time
45

46. Who uses Scrum?
• Microsoft, Sun, Sammy Studios, Siemens, CNA, State Farm,
State Street Bank, Philips, BBC, IBM, SAIC, LMCO, APL, Ariba,
Federal Reserve Bank, HP, Motorola, Nokia, TransUnion, IDX,
Siemens Medical, Gestalt, Yahoo, Conchango, BMC, Lexis-Nexis,
Bently Systems, Bose, CapitalOne,Federal Reserve Bank,
ClearChannel, Xerox, Patient Keeper, British Telecom, PayPal, …

47. What is Scrum process flow

48. Scrum process flow
Planning
Product owner and team decide which stories are actually
feasible to be moved from the Product backlog to the Sprint
backlog.
Sprint
The team is left alone to perform the user stories which it
has committed itself in the planning meeting. The product
owner may attend the “daily scrums” if a granular status
update is desired.
Review
The team presents its work and verifies what it has done
indeed satisfies the utmost desires of the product owner.

49. User Stories in SCRUM

50. User Stories
• A user story is a software system requirement formulated as one or two
sentences in the everyday language of the user.
• It is written by the Product Owner, with the help of the ScrumMaster and Team, if
desired and necessary.
• Once completed, it is put in the Product Backlog and prioritized, by the Product
Owner, by its relative placement to other user stories.
• Before a user story is to be implemented, appropriate acceptance criteria must
be written to ensure proper testing or otherwise determine whether the goals of
the user story have been fulfilled.
• Some formalization finally happens when the developer accepts the user story
and the acceptance procedure as his work specific order.

51. User Stories - structure

52. User Stories - structure
• Who (user role) – is this a customer, employee, system administrator?
• What (goal) – What is the specific functionality that is to be achieved or
developed?
• Why (reason) – Helps the developer to understand the broader scope of the
story and eliminate any ambiguities that may arise.
• Putting it all together: As a [user role], I want to [goal], so I can [reason].
• “As a registered user, I want to log in, so I can access subscriber content.”

53. USER STORIES
CHARACTERISTICS – I.N.V.E.S.T.

54. User Stories – I.N.V.E.S.T.
• Independent - For some systems, it's near impossible to make each feature completely
independent. In other solutions, e.g. web sites, it's easier. But it's an important aspiration.
User Stories should be as independent as possible.
• Negotiable - User Stories are not a contract. They are not detailed specifications. They
are reminders of features for the team to discuss and collaborate to clarify the details near
the time of development.
• Valuable - User Stories should be valuable to the user (or owner) of the solution. They
should be written in user language. They should be features, not tasks.
• Estimatable - User Stories need to be possible to estimate. They need to provide
enough information to estimate, without being too detailed.
• Small - User Stories should be small. Not too small. But not too big.
• Testable - User Stories need to be worded in a way that is testable, i.e. not too
subjective and to provide clear details of how the User Story will be tested.

55. Scrum has been used for:
• Commercial software
• In-house development
• Video game development
• Contract development
• life-critical systems
• Fixed-price projects
• Satellite-control software
• Financial applications
• Websites
• ISO 9001-certified
• Handheld software
applications • Mobile phones
• Embedded systems • Network switching applications
• 24x7 systems with 99.999% • Some of the largest applications in
uptime requirements use