The document discusses an introduction to using Mini Scum Game to learn agile concepts and practices such as Scrum. It explains that the goal is to have a hands-on practice of Scrum through playing the game. It outlines the Scrum ceremonies that will be part of the game, including sprint planning, daily stand-ups, sprint reviews, and retrospectives. It also provides instructions on how to structure teams and assign roles of product owner and team members for the game.

2.  Background
 Why play Mini Scum Game
 Mini Scum Game
 Continuous Improvement

4.  Trend Micro RD
 Commercial product development
 Agile experience
› Workshop
› Daily work
› NGO

5.  Organization & Culture
› Techies, Sales & Managers
› Component team
› Waterfall
› Spec, spec, spec for record
› Early system-wise optimize
 Members
› 普遍聽過Agile & Scrum
› 好奇這東西有用嗎
› 不如多花點時間寫code

6.  Good practice
› Focus on value rather than task
› Empowerment
 Support from manager
› Reduce technical debt

8.  A hands-on practice
 A rough idea of Scrum
 Iteratively improve in real practice
 Make questions more specific

9.  Start from…
› Ceremony
 Manifest to Action
› Current organization
› Familiar topic

11.  復康巴士線上預約系統

12.  復康巴士
› 載送身心障礙者的公共汽車，多加裝了方便身心
障礙者上下車的輔助器材
› 有些有固定的運行路線，也有些採預約制，點對
點接送身心障礙者
 線上預約系統

13.  At least four people a team
 Role
› Product Owner: 1
› Team: >= 3

14.  Be responsible for maximizing the value
of the product
 In this game
› The one who have “Customer Insight”
› The one who can ask the customer

15.  Deliver potentially shippable product
increment
 Self-organizing & cross-functional
 In this game
› Not cross-functional
› UI designer, RD, QA

17.  Sprint planning – part 1 (Skip)
 Sprint planning – part 2
 Daily scrum
 Product backlog refinement (Skip)
 Sprint review
 Sprint retrospective

18. PO + Team:
What I want
What can be done

20.  Present and clarify high order PBIs and
new PBIs
 Refine new PBIs
 Select PBIs based on order

21.  As a system admin, I want to see the
alarm being reported when board is
missing, so that I can know when certain
board signal is lost
› Alarm reported with right slot ID
› Know the time the alarm happen
› Alarm be reset when board is re-plugged in
› Severity of the alarm can be configured
from 1~5

22. ID Product Backlog Item Rank
1 As a user, I want to create an account.
2 As a user, I want to view the available
session times.
3 As a user, I want to make a reservation.
4 As a user, I want to cancel a
reservation.
5 As an administrator, I want to have an
overview.
6 As a driver, I want to view my
schedule.

23.  Tasks
› Write two more product backlogs in sheet
 Start from writing backlog as user story
 The story text we write on cards is less
important than the conversations we have.
› Sort, discuss and refine
 Can add note, rewrite, split or merge
 Focus on value for user
 Do not go into detail or implementation too
early
› Select PBIs for the sprint

24. Team:
What I do
How the work will be done

25.  Having a DoD in place, available and
visible to everyone is extremely important.
 Remind what should be done and what
the general acceptance criteria are for
every item

27.  Team selects items from the PBI they can
commit to completing
 Sprint backlog is created
› Tasks are identified and each is estimated (1-
16 hours)
› Collaboratively, clarify spec. and
dependency
 High-level design is considered

28. 8 Tino
8 > 4
5-2
Pattern serializer -
Write detailed design
document
Estimation Owner
Progress
Product backlog ID
Sprint backlog description

30.  As a user, I want to make a reservation.
 Length of a sprint planning: 10 min.
 Length of a sprint: 5 days (4 min. per day)
 Current organization
› UI designer, RD, QA

31.  Tasks
› Discuss the PBI (PO + team)
› Decide acceptance criteria (PO + Team)
› Select owner of each item (Team)
› Breakdown into sprint backlog (Owner)
› Estimate effort (Owner)

32.  Possible Delivery
› UI designer
 Mockup
› RD
 Pseudo code
› QA
 Test case
 In the Sprint Review
› QA demonstrates the work that it has “Done”
and answers questions about the Increment

33. Team

34.  Team meets every day for a quick status
update
 Answer the three questions
› What did I accomplish yesterday?
› What will I do today?
› What obstacles are impeding my progress?

35.  Share commitment
› more important than sharing progress or status
 Communicate status
› the team updates each other instead of a manager
 Identify obstacles
› not intended to remove any particular obstacle
› but rather to provide a forum for people to identify obstacles
 Set direction and focus
› Continually remind the team what that direction is.
 Build a team
› regularly communicating, working, and helping each other

36.  Update sprint backlog
› Status and progress

37.  Tasks
› Make your delivery everyday
 1 day = 4 minutes
› Daily Scrum in 2 minutes
 Restriction
› Sit when working
› Stand when discussion
› Can’t leave your seat

38. PO + Team

39.  Get hands on with what’s been built
 Inspect the quality
 See whether the commitment was
completed
 Attended by everyone
› Product Owner,
› Team,
› Scrum Master,
› Stakeholders and
› end users!

40.  The majority of the Sprint Review is spent
with
› presenting functionality,
› answering questions regarding the presentation
› noting changes desired.
 After presentation, the stakeholders are
polled to
› get their impressions, desired changes, and their
priority.
 The PO discusses with stakeholders/Team
potential rearrangement of the Product
Backlog

41.  Tasks
› Review progress of each backlog
› Demo
› Usability Test

42. Team

43.  A Special meeting that take place at the
end of a period of work
 In a retrospective
› Steps back
› Examine the way they work
› Analyze and identify ways they can improve

44.  Retrospectives cannot fix everything
 Retrospectives aren’t the place for
individual performance feedback
 Retrospectives aren’t the answer for
inadequate technical or collaboration
skills
 Retrospectives may not correct faulty
mental models of software development
or of how organizations work

45.  Do help teams think, learn, and decide
together
 Make time for teams consider ways to
redesign their work and team culture

46.  Tasks
› Post everyone’s opinion on board
 Good
 Bad
 Happy
 Unhappy
› Vote on importance
› Follow-up and set action item

48.  Do the right thing
› Help you find what to do
 Do the thing right
› Help you evaluate how to do

50. 2-50
Source: Scrum Guide
http://www.Scrum.org/storage/scrumguides/Scrum%20Guide.pdf#view=fit
Transparency
Inspection
Adaptation

51.  PO
› PO is responsible for the product success?
› Who should understand the customers?
 PBI
› Clear Acceptance Criteria
› Follow the specification? Follow your
competitors?
› Minimum Viable Product
› Must be an online reservation system

52.  Look ahead
› Learn more about the product during each
sprint
 Adopt before the next Sprint Planning

53.  Collaboration only in Daily Scrum?
 Self organizing
 Cross-functional

54.  Potentially Shippable Product Increment
› Walking Skeleton
 Collect feedback
 Undone tasks

55.  Did Scrum solve any existing problem?
› Still delay
 Early or late discover
 Hide it or face it
› Still have many problem
 Highlight the problem
 Belong to team
 Good framework implies good solution?
 Component team to Feature team
› Sharing, pairing