A presentation of Scrum basics.

1. Scrum…getting software done

2. What is Scrum?
An Agile framework for completing complex projects
– Simple concepts, difficult to implement
Practices
Principles
Values

3. How Scrum Helps
IT systems + abstract ideas + requirements + PEOPLE = craziness!
– Many pieces of unreliable and complex systems
– No tangible products or measurable designs
– Requirements….
• Not fully known
• Frequently changing
• Hard to articulate
• Many stakeholders
– People…we’re just nuts Requirements
Technology
Graph: http://www.gp-training.net/training/communication_skills/consultation/equipoise/complexity/stacey.htm

4. How Scrum Helps
• Defined processes, like waterfall, don’t handle
complexity well
Traditionally we:
– Define the requirements up front
– Break down the work
– Estimate effort/duration
– Plan out the work
– And then we begin to build
– But don’t change the plan!
This • then
That • then
This • then

5. How Scrum Helps
• Empirical processes account for complexity
– Visibility: aspects of the process that affect the
outcome must be visible, and correct.
– Inspection: aspects of the process must be inspected
frequently enough to detect unacceptable variance
– Adaptation: if through inspection, it is found there is
unacceptable variance then the process must be
changed as quickly as possible to minimize further
deviation
• Scrum uses a short iterative cycle to verify
everything is going like we had hoped

6. SCRUMMY VALUES & PRINCIPLES
The ideas that guide a Scrum implementation

7. Agile Values
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.
http://agilemanifesto.org/

8. Agile Principles
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.

9. Scrum Values
• Commitment and Focus
• Openness
• Respect
• Courage
http://www.scrumalliance.org/pages/code_of_ethics

10. Commitment and Focus
• Commitment is our willingness to dedicate ourselves to a goal and to do our best
to meet that goal.
• Focus means that we concentrate on and are answerable for doing the things that
we have committed ourselves to do, rather than allowing ourselves to become
distracted or diverted.
As practitioners in the global Scrum community:
– We take responsibility for and fulfill the commitments that we undertake – we do what we say
we will do.
– We make decisions and take actions based on the best interests of society, public safety, and
the environment.
– When we make errors or omissions, we take ownership and make corrections promptly. When
we discover errors or omissions caused by others, we promptly communicate them to the
appropriate individual or body. We accept accountability for any issues resulting from our
errors or omissions and any resulting consequences.
– We protect proprietary or confidential information that has been entrusted to us.
– We proactively and fully disclose any real or potential conflicts of interest to the appropriate
parties.
http://www.scrumalliance.org/pages/code_of_ethics

11. Openness
• Openness: affording unobstructed entrance and exit; not shut or closed.; Carried
on in full view;*
As practitioners in the global Scrum community:
– We earnestly seek to understand the truth.
– We strive to create an environment in which others feel safe to tell the truth.
– We are truthful in our communications and in our conduct.
– We demonstrate transparency in our decision-making process.
– We provide accurate information in a highly visible and timely manner.
– We make commitments and promises, implied or explicit, in good faith.
– We do not engage in or condone behavior that is designed to deceive others.
http://www.scrumalliance.org/pages/code_of_ethics * http://www.thefreedictionary.com/openness

12. Respect
• Respect means that we show a high regard for ourselves, others, and the resources
entrusted to us. Resources entrusted to us may include people, money, reputation, the
safety of others, and natural or environmental resources.
• An environment of respect engenders trust, confidence, and performance excellence by
fostering mutual cooperation and collaboration — an environment where diverse
perspectives and views are encouraged and valued.
As practitioners in the global Scrum community:
– We respect the rights and beliefs of others.
– We listen to others’ points of view, seeking to understand them.
– We approach directly those persons with whom we have a conflict or disagreement.
– We conduct ourselves in a professional manner, even when it is not reciprocated.
– We negotiate in good faith.
– We do not exercise the power of our expertise or position to influence inappropriately the
decisions or actions of others in order to benefit personally at their expense.
– We do not discriminate against others based on, but not limited to, gender, race, age, religion,
disability, nationality, or sexual orientation.
– We do not engage in any illegal behavior.
http://www.scrumalliance.org/pages/code_of_ethics

13. Courage
• Courage means that we have the daring to do the best that we can and the
endurance not to give up. We have the determination and resolution to take
ownership of the decisions we make or fail to make, the actions we take or fail to
take, and the consequences that result.
As practitioners in the global Scrum community:
– We share bad news even when it may be poorly received.
– We avoid burying information or shifting blame to others when outcomes are negative.
– We avoid taking credit for the achievements of others when outcomes are positive.
– We would rather say, “no,” than make false promises.
– We accept the possibility of failure but also know that we can learn from failure and
apply those learnings to our next attempt.
– We acknowledge that change is inevitable, that change leads to growth, and that growth
guides us toward improvement.
– We admit when we need help and we ask for help.
http://www.scrumalliance.org/pages/code_of_ethics

14. How can we better adopt these values
and principles?
• Individuals and
interactions over processes
and tools
• Working software over
comprehensive documentation
• Customer
collaboration over contract
negotiation
• Responding to
change over following a plan
• Commitment and Focus
• Openness
• Respect
• Courage
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.

15. SCRUMMY ROLES
The people in Scrum

16. The people in Scrum
• The Team
– Self-organizes to get the work done
• Product Owner
– Responsible for the business value of the project
• ScrumMaster
– Ensures the team is functional and productive

17. The Team
• Is cross-functional
• Is right-sized (the ideal size is seven -- plus/minus
two -- members)
• Selects the sprint goal and specifies work results
• Has the right to do everything within the
boundaries of the project guidelines to reach the
sprint goal
• Organizes itself and its work
• Demos work results to the product owner and
any other interested parties.
http://www.scrumalliance.org/pages/scrum_roles

18. The Team
• Cross Functional
– Different specialties
• Developers
• Testers
• Tech writers
• Usability engineers
• Architects
• Designers
• Analysts
• Any one needed to complete the sprint!
– Fuzzy role boundaries
– Common goal
– Each member is held accountable to
reach the goal

19. The Team: A Lacrosse Story

20. The Team: A Lacrosse Story

21. The Team
• Self-organizing
– Pulls in work
– Plans their own work
– Cooperative development
and decision making
– Authority to do what is
needed to reach the sprint
goal
– Self inspecting

22. Product Owner
• Decides what will be built and in which order
• Defines the features of the product or desired outcome
of the project
• Chooses release date and content
• Ensures profitability(ROI)
• Prioritizes features and outcomes according to market
value
• Adjusts features/outcomes and priority as needed
• Accepts or rejects work results
• Facilitates sprint planning ceremony
• "single wringable neck"
http://www.scrumalliance.org/pages/scrum_roles

23. Product Owner
• What makes a great
Product Owner?
http://agilescout.com/infographic-what-is-a-product-owner-
responsible-for/

24. Product Owner
• What makes a great
Product Owner?
– Visionary
– Open to negotiation
– Available within reason
– Informed about product
– Communicative
http://agilescout.com/top-10-essential-product-owner-characteristics/

25. Product Owner
• Answers 4 questions:
1. Why are we building
this, and what problem
are we solving?
2. Who is it for: Primary
Audience? Secondary?
3. What is important to
that audience?
4. What are the
constraints?
http://agilescout.com/agile-product-management-product-owners-
are-key/

26. ScrumMaster
• Ensures that the team is fully
functional and productive
• Enables close cooperation across
all roles and functions
• Removes barriers
• Shields the team from external
interferences
• Ensures that the process is
followed, including issuing
invitations to daily scrums, sprint
reviews, and sprint planning
• Facilitates the daily scrums
http://www.scrumalliance.org/pages/scrum_roles

27. ScrumMaster
• The goals
– Increase collaboration between the team and
product owner
– Remove impediments inside the organization
– Help the team reach their potential

28. ScrumMaster
• The goals
– Increase collaboration between the team and product
owner
– Remove impediments inside the organization
– Help the team reach their potential
• The obstacles
– Waterfall development
– Command and control
– Breaking down barriers between departments
– Skeletons in the closet

29. ScrumMaster
• Some ScrumMaster traps
– Responsible for product delivery

30. ScrumMaster
• Some ScrumMaster traps
– Responsible for product delivery
– Becoming a manager

31. ScrumMaster
• Some ScrumMaster traps
– Responsible for product delivery
– Becoming a manager
– Making team decisions

32. SCRUMMY ARTIFACTS
The deliverables

33. Artifacts
• Product Backlog – list of items to be done
• Sprint Backlog – items to be done in this sprint
• Product Increment – shippable product
Also, the burn down charts

34. Product Backlog
• Product
Owner owns
and prioritizes
• Anyone can
add to it
• If it isn’t in
the product
backlog, it
doesn’t exist

35. Product Backlog
• Is software ever “correct” the first release?
– More requirements will emerge as the product is
built…it’s what is expected and wanted
– Customer feedback and changes are reflected in
backlog
• Invest time and money only in high-priority
features
– 80% of value from 20% of features

36. Product Backlog

37. Product Backlog Items
• Just enough detail to complete the item in one
sprint
– Might contain
• business processes
• Data needed
• Designs
• Items further in the future can be larger and
more vague
• Item descriptions should be as brief as possible
– User stories!

38. User Stories
• Three C’s
– Card : User stories are written on cards. The card does
not contain all the information that makes up the
requirement.
– Conversation: The requirement itself is communicated
from customer to programmers through conversation:
an exchange of thoughts, opinions, and feelings.
Usually over a period of time.
– Confirmation: At the beginning of the iteration, the
customer communicates to the programmers what
she wants, by telling them how she will confirm that
they’ve done what is needed.
http://xprogramming.com/articles/expcardconversationconfirmation/

39. User Stories
• Describes a feature
from a user’s
perspective
As a user I want to filter my search
results by order # so that I don’t
have to scroll through all the
results

40. User Stories
• I ndependent – schedule and implement in any order
• N egotiable - co-created by the customer and programmer
• V aluable - valuable to the customer
• E stimable - can be estimated
• S mall – easy to know what's in the story's scope
• T estable - I understand what I want well enough that
I could write a test for it
http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

41. User Stories
• Acceptance Criteria
– Product owner defines acceptance criteria before
sprint planning
– During sprint planning acceptance criteria are
discussed and negotiated
– Should be short and easy to understand
As a user I want to filter my search
results by order # so that I don’t
have to scroll through all the
results
Acceptance Criteria:
Entering a order # should only show
orders with that order #.

42. When is a Story Done?
• Definition of Done
– Applies to all stories
– States the deliverables for each story (code, etc)
DoD
Helps to build the thing right
(quality)
Acceptance Criteria
Helps to build the right thing
(functionality)
vs

43. Definition of Done
http://www.scrumalliance.org/articles/107-how-do-we-know-when-
we-are-done

44. Sprint Backlog
• The team commits to a certain number of
stories during Sprint Planning
• Each Story also contains technical tasks to
build it
http://www.mountaingoatsoftware.com/scrum/sprint-backlog

45. Reporting Progress
• Task Board
– Electronic vs Wall

46. Reporting Progress
Burndown Burnup

47. Product Increment
• The product with the new functionality built
during the sprint
• New features are “done”
• Potentially shippable
“Scrum requires Teams to build an increment of product
functionality every Sprint. This increment must be potentially
shippable...the increment must be a complete slice of the product. It
must be “done.” Each increment should be additive to all prior
increments and thoroughly tested, ensuring that all increments
work together.”
Scrum Guide: http://www.scrum.org/scrumguideenglish/

48. SCRUMMY CEREMONIES
Aka Meetings

49. Ceremonies
• Sprint Planning
– Plan the next iteration
• Daily Scrum
– Collaborate with team members
• Sprint Reviews
– Show off what was built
• Sprint Retrospectives
– What went well? what did not go well?

50. Sprint Planning
• Who Participates?
– The team
– Product Owner
– Customers and Management
• Inputs
– Product Backlog
– Team capabilities
– Business Conditions
– Definition of Done
– Technology
– Current Product
– Velocity
Sprint Backlog
• Detailed tasks
• Priorities
• Detailed Estimates

51. Daily Scrum
• Who participates?
– The team
• Each team member answers 3 questions
– What did you do yesterday?
– What are you doing today?
– What is getting in your way?
• It is not a status report to anyone
• It is a way to collaborate with team members
• Timeboxed to 15 minutes

52. Scrum of Scrums
• Some suggestions from Mike Cohn
– A designated rep from each team attends
– Timeboxed 15min for daily meetings
• Leave time after for resolving problems
– Problems that arise should be addressed and fixed
– Suggested Questions:
1. What has your team done since we last met?
2. What will your team do before we meet again?
3. Is anything slowing your team down or getting in their
way?
4. Are you about to put something in another team’s way?
– No names are used in reporting…speeds things up
http://www.scrumalliance.org/articles/46-advice-on-conducting-the-
scrum-of-scrums-meeting

53. Sprint Review
• Who participates?
– The team
– ScrumMaster
– Product Owner, Customers
– Stakeholders and other interested parties
• Team presents what it is has accomplished
– Demo or fair style
• Verify “done” with customers/product owner
• Don’t hide undone work

54. Sprint Review w/ Multiple Projects and
Teams
• Demo format
– Planned agenda so customers can come and go to
see their product
• Fair format
– Teams set up booths that customers can interact
with the product

55. Sprint Retrospective
• Who participates?
– The team
– The ScrumMaster facilitates
• An open environment is needed
– Means no managers or product owners
• What went well, what didn’t
– Improvements prioritized
– Team devises solutions

56. Review
• Agile and Scrum Values and Principles
– Individuals and interactions over processes and tools, Completed
functionality over comprehensive documentation, Customer
collaboration over contract negotiation, Responding to change
over following a plan
– Commitment, Focus, Openness, Respect, Courage
• 3 Roles
– Product Owner, Scrum Master, The Team
• 4 Ceremonies
– Sprint planning, Daily scrum, Sprint review, Sprint retrospective
• 3 Artifacts
– Product backlog, Spring backlog, Product increment

57. Where to now?