Scrum in One Day is a presentation about Scrum and agile principles. It introduces key Scrum concepts like artifacts, roles, and events. The presentation defines Scrum, its pillars of transparency, inspection, and adaptation. It explains Scrum artifacts like product backlog, sprint backlog, burnup and burndown charts. It also covers agile user stories and inception decks. The presentation provides an overview of agile and Scrum to help attendees understand this framework for iterative software development.

1. Scrum in One Day
Alexandre Cuva
Coach Agile, LTM3, CSM, CSPO, HSPTP
PMDay Bucharest 2012

2. Practical Stuff

3. Alexandre Cuva
Email : Organizational Coaching
alexandre.cuva@gmail.com (Management 3.0, Scrum)
Twitter: @cuvaalex
Team Coaching
Blog: http://agile-
alexcuva.blogspot.com/ (Scrum, XP, Kanban)
Phone: +41 78 715 8309 Technical Coaching
(TDD, BDD, C#, Java, Groovy)
Agile Training
(Management 3.0, Agile, Scrum, XP)

4. Observation
The complexity is growing fast

5. Observation
The current standard management system, does not provide satisfaction to
all.

6. “Organizations can become learning networks of
diverse individuals creating value, and the role
of leaders should include the stewardship of the
living rather than the management of the
machine.”
http://www.stoosnetwork.org

7. Agile Overview
Agile Tree
Profit
Practices
Principles Values
Source: Coaching Agile Teams by Lyssa Adkins

8. Agile Overview
Agile Manifesto
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.
Source: Agile Manifesto : http://www.agilemanifesto.org

9. Agile Overview
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.
Source: Agile Manifesto : http://www.agilemanifesto.org

11. Learning Framework
SCRUM OVERVIEW

12. Scrum Overview
Scrum three Pillars
Transparency Inspection Adaptation

13. Scrum Flow
Product Sprint Selected Sprint
Backlog Planning 1 Product Backlog Planning 2
Vision
Sprint
Retrospective Backlog
Review Meeting Daily Scrum

14. Scrum a Learning Framework
SCRUM ARTIFACTS

15. Scrum Artifacts
Velocity
the amount of product backlog that a team can handle in one single sprint
Quantified in story points
Story point is an arbitrary measure to quantify the required effort to finish an
user story. Namely, how hard the story is. Loosely based on Fibonacci series.
Business Solutions

17. Scrum Artifacts
Product BurnUp
Display work delivered so far in the release to predict whether the release date will
be met (extrapolation)
Business Solutions

18. Scrum Artifacts
Product Release Burndown

19. Scrum Artifacts
Sprint Backlog
The Sprint Backlog defines the work the Development Team will perform to
turn Product Backlog items into a “Done” Increment.
The Sprint Backlog makes visible all of the work that the Development Team
identifies as necessary to meet the Sprint Goal.
As new work is required, the Development Team adds it to the Sprint Backlog.
As work is performed or completed, the estimated remaining work is updated.
When elements of the plan are deemed unnecessary, they are removed.
Only the Development Team can change its Sprint Backlog during a Sprint.

20. Scrum Artifacts
Sprint Burndown

21. Scrum Artifacts
Scrum Board

22. Scrum Artifacts
Definition of done
When can a story be considered as “done” and accepted?
Done defines what the Team means when it commits to “doing” a Product Backlog
item in a Sprint.
Exit criteria must be defined in advance for every individual User story at the sprint
planning. E.g.:
• Release (baseline created): label submission
• Code Review conducted
• Unit Tests successfully run and integrated with the CI system
• Code coverage and static analysis done
• Verified Business Solutions
• Tests for regression automated and successful
• Demo to the Product Owner for acceptance
• User, API and Design documents completed
Lingo term in the Agile religion for “done”: “sashismi”

24. Learning Framework
USER STORIES

25. User Stories
What is a User Story
A user story describes functionality that will be valuable to either a user or
purchaser of a system or software.
User stories are composed of three aspects:
• A written description of the story used for planning and as a reminder
• Conversations about the story that serve to flesh out the details of the story
• Test that convey and document details and that can be used to determine when a
story is complete

26. User Stories
Epics, Themes and User Stories
User Stories
Themes
Epics

27. User Stories
Attributes of a good user story
Independent
Avoid introducing dependencies cause this can lead to prioritization, estimating and
planning problems
Negotiable
Stories are short descriptions of functionality, the details of which are to be negotiated
with the customer. Important details shall be annotated as they surface
Valuable to users or customers
Avoid stories that only are valuable for developers
Have the customer user or their representative write the stories
Estimable
If there are lack of knowledge, make a spike to gather further info
Small
Split stories (or combine them) into the right size
Testable
Developers must be able of determine when they are DONE

28. User Stories
The three aspect of user stories
• Stories are traditionally written on note cards
Card • Cards may be annotated with
estimates, notes, etc.
• Details behind the story come out during
Conversation conversations between stakeholders, product
owner and team
• Acceptance tests confirm that the story was
Confirmation coded correctly

29. User Stories
Format
Business Solutions

30. User Stories
Examples of user stories
As a surfer, I want As a trader, I want
to ride the wave so open a position, so
that I will have I can short a
great fun. EURUSD pair.

32. Retrospective

33. Learning Framework
THE INCEPTION DECK

34. The Inception Deck

35. The Inception Deck
2. The Elevator Pitch

36. The Inception Deck
3. Design the Box

37. The Inception Deck
4. Not List

38. The Inception Deck
5. Meet you neighbors

39. The Inception Deck
And the last 5 things to remember
6. Show the solution.
7. Ask what keeps us up at night.
8. Size it up
9. Be clear on what’s going to give
10. Show what it’s going to take.

42. Alexandre Cuva
Email : Organizational Coaching
alexandre.cuva@gmail.c (Management 3.0, Scrum)
om Team Coaching
Twitter: @cuvaalex (Scrum, XP, Kanban)
Blog: http://agile- Technical Coaching
alexcuva.blogspot.com/ (TDD, BDD, C#, Java, Groovy)
Phone: +41 78 715 8309 Agile Training
(Management 3.0, Agile, Scrum, XP)