I use these slides to introduce teams to Scrum. It covers the basics.

1. Reflections by
Juan Santisi
CSPO
SCRUM IT UP!

2.  Individuals and interactions over processes and tools
 Working software over comprehensive
documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan
AGILE MANIFESTO

3. 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.
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.
THE ’12’ PRINCIPLES

4.  Focus
 Openness
 Respect
 Courage
 Commitment
SCRUM VALUES

5.  Project development is performed in 2-4 weeks
 Product Owner Creates a prioritized backlog
 Highest Priority features delivered first
 The team meets each day to assess progress
 At the end of the sprint, the deliverables are reviewed by the
business customers
 The team reflects on the process
SCRUM

6. SCRUM IS A PROCESS
ProductBacklog
Prioritized product features desired by client
15 min. Daily meeting.
Team members respond to basics:
A. What did you do since last Scrum Meeting?
B. Do you have any obstacles?
C. What will you do until next Scrum Meeting?
24 hours Scrum
30
DAYS
24
HOURS
New
functionality
Backlog
Items
expanded by
team
Sprint Backlog
Features
assigned to
sprint

7.  Minimum viable feature (MVF or MVP)
 How do you determine if you need more resources in a Scrum
team?
 How big is a Scrum team? 7 +/- 2
 Who owns the Product Backlog?
 For every Sprint we should have a goal?
SCRUM GENERAL RULES

8.  Revisit our Team Charter
 Revisit our DoD
DEVELOPMENT TEAM

9.  Determines a shared understanding of what “Done means”
 Defines the notion that the Product Increment is of high
quality to be shippable
 Work remaining “Not Done” is PBI that goes into the Product
Backlog
 “When the Product Increment is delivered, it needs to be
"done" according to a shared understanding of what "done"
means. This definition is different for every Scrum Team, and
as the team matures, the Definition of Done will expand and
become more stringent.”
http://agileatlas.org/atlas/scrum#product-increment
DOD

10. DEFINE DOD
With a Sprint
Code is
checked-in
Code Review
Is Complete
All unit tests
Are passing
With a PBI
Integration
Test Passing
Performance
Test Passing
With a Release
Security
Audit
Passing
Regression
Test Passing
Acceptance
Criteria
Passing

11. USER STORY REVIEW
 What’s a User Story? It’s a simple, clear, short description of
a customer valued functionality.
 3 parts:
 Written Description used for planning
 Conversation to flush out the details
 Tests to determine completeness
 3C’s: card, conversation, confirmation
 Representation rather than documentation.

12.  As a {role}, I want {feature} so that {value}
 Define the acceptance criteria for each user story
 Attributes of a good user Story
 Independent
 Negotiable
 Valuable
 Estimate-able
 Small
 Test-able
USER STORY FORMAT

13. USER STORY TEMPLATE
Title Priority
As a [type of user], I want to [goal/functionality] so that
[business value]
Notes:
Assumptions:
Constraints:
Estimate:

14. USER STORY EXAMPLE
Check Out using Credit Card 25
As a book shopper, I can checkout using my credit card so that I
can purchase a selected book.
Notes: Support MC, Visa, AMEX
Constraint: Must Use Chase Clearinghouse
13 pts?

15. ACCEPTANCE CRITERIA
 Ask the User who’s creating the story to also capture the
acceptance criteria. The acceptance criteria is what’s used to
measure that the story is complete.
 Format for the Acceptance Criteria
Given [context]
When [some event]
Then [Outcome]

16. ACCEPTANCE CRITERIA - EXAMPLE
 Checkout using Credit Card
Test with valid mc, visa, amex: pass
Test with other credit cards: fails
Test with expired cc: fails
Test with invalid cvv: fails
Test with invalid zip: fails

17. PERSONAS?
 Personas are used to represent your market segments or
system users into stakeholders.
 Use personas to help you define your user stories.
 SFDC – Roles & Profiles
 Market Segments (Product specific)
 Data to Include: Name, Photo, Title, Description
 Data to consider: User responsibilities, Domain Knowledge,
Success Goals, Pain Points, Expected frequency of system
usage…

18. PERSONAS EXAMPLE
About:
His responsibility is to close big
deals on key accounts. The
company needs a process to
identify key accounts so that he
can maximize his time. Juan is a
CRM and mobile savvy user who’s
actively looking for the CRM to
provide him with the most
accurate sales information.
Context:
Juan the Sales rep is always on the road. He needs
access to key accounts and all his contacts on a
mobile device. He’s always working on closing his
next deal. Depends heavily on Sales Ops.
Implications:
Wants a process to identify key
account & related opportunities.
Is keen on being 100% mobile.
He needs reports and dashboards
that show the key account pipeline
on mobile. Also, he wants to see all
previous sales for each account that
he visited.

19. USER STORIES BEST PRACTICES
 Write the story from the User’s perspective
 Understand the User’s goal of the story
 Understand the User’s value from the story **
 Use human users, unless you are integration systems.
 Avoid Using generic “user” or “as a customer”
 Think Personas.
 What are the Pain Points that the User’s have?
 What’s the value that we are trying to build?
 Capture the success criteria. This is very important.

20. USER STORIES FAQ
 We have user stories that are not in this format. Can we use
the stories? Yes, re-format the stories and capture the
Acceptance Criteria.
 We have user stories that are not depicted as humans? This is
common when systems are being integrated and that one
system, needs the functionality in order to capture value.
 We have user stories that define what technical approach
should be used? User stories should not outline a specific
technical solution, rather they should depict a business
function that a user needs and the value.

21. ADDITIONAL TEAM ACTIVITIES
 Create Story Maps: This is a key activity that will be covered
with another presentation.
 Product Owner prioritizes the user stories in the backlog daily.
 The development team will take the user stories and break
them down into tasks [Similar to WBS] during Sprint Planning.
 Some user stories will be moved into “Epics” if they are to big
to complete during the sprint timeframe.

22.  Is held at the end of each Sprint.
 Dedicated time for the team to focus on:
 What was learned during the sprint.
 What can the team improve on for the next sprint.
 1-2 hours of retrospective time for each week of development
 Who should attend?
 Development team
 Product owner
 The 12 Principle – “At regular intervals, the team reflects on
how to become more effective, then tunes and adjusts its
behavior accordingly.”
 Teams that effectively use retrospectives feel a strong sense
of empowerment as they continually improve the way they
work.
SPRINT RETROSPECTIVE

23. AWS PRODUCT ROLLOUT - TEMPLATE
Vision
Submit and store content from the Enterprise Content Repository into
AWS Cloud. And provide a unified delivery service to partners.
Mission
Provide Enterprise Services (ES) that enables systems & users to
submit content into the AWS cloud. The ES should be automated and
provide mediation, security and delivery capabilities.
Success Criteria
The Enterprise Services (ES) must be operational by MM-DD-YYYY
The following content set must be accessible: A, B, C and D.
The ES will provide reports on the content submitted and retrieved.
The following Service Level Agreements – SLA’s must be met…

24.  Is a metaphor developed by Ward Cunningham to help us deal
with a common problem
 “Doing things quick and dirty set us up with a technical debt,
which is similar to financial debt.
 Leads to extra effort that we have to do in the future(as a form of
payment on the debt)
 Two choices – continue to make payments on the interest or pay
down the principal (refactoring)
 The savvy developer treats technical debt just as the
entrepreneur does financial debt. They use it. It speeds
delivery, so long as it is properly managed.
 http://www.c2.com/cgi/wiki?TechnicalDebt
TECHNICAL DEBT

25.  Calculation of the Debt
 Debt(in man days) = cost_to_fix_duplications +
cost_to_fix_violations +
cost_to_comment_public_API +
cost_to_fix_uncovered_complexity +
cost_to_bring_complexity_below_threshold +
cost_to_cut_cycles_at_package_level
CALCULATING TECHNICAL DEBT

26. TECHNICAL DEBT - EXAMPLE