2. SCRUM
WHAT IS SCRUM?
‣ One of the agile methodologies
‣ A framework within which people can address complex
adaptive problems while productively and creatively
delivering products of the highest possible value
‣ All activities preformed in scrum are based on agile
manifesto and scrum values
‣ Team needs to practice these to achieve effective team
work and continuous improvement
‣ The scrum values are Commitment, Courage, Focus,
Openness and Respect
2
3. SCRUM
AGILE MANIFESTO
‣ We are uncovering better ways of developing software
by doing it and helping other do it
‣ Individuals and interactions over processes and tools
‣ Working software over comprehensive documentation
‣ Customer collaboration over contract negotiation
‣ Responding to change over following plan
‣ None of us is as strong as all of us
3
4. SCRUM
SCRUM VALUES
‣ Commitment - As total team is accountable for the deliverables, team
becomes more committed towards success
‣ Courage - Any person in scrum team is not alone; he/she has support from
team which gives courage to deal with challenges
‣ Focus - In Scrum, as team always focuses on less number of things in each
sprint, team works together and produce business value faster to the
customer
‣ Openness - As a member of a team, you need to express how team is doing
and report if there are any impediments so that concerns can be addressed
by working together
‣ Respect - Team is working together as a family. They share both success and
failure. In team, you respect each other and help each other to reach a
common goal as you do in family
4
9. SCRUM
SCRUM RULES
‣ Scrum Guide is the Scrum rulebook maintained by Ken
Schwaber and Jeff Sutherland.
‣ http://www.scrumguides.org/docs/scrumguide/
v2016/2016-Scrum-Guide-US.pdf
9
13. SCRUM
THINGS
‣ The product is describes as a list of features: the
backlog
‣ The features are described in terms of user stories
‣ The scrum team estimates the work associated with
each story
‣ Features in backlog are ranked in order of importance
‣ Result: a ranked and weighted list of product features,
a roadmap
‣ The product owner owns the product backlog
13
18. SCRUM
USER STORIES - COMMON PITFALLS
‣ Lack of context
‣ Fail to deliver value
‣ Overly specified
‣ User/Client doesn’t know
what they want
‣ No prioritisation
‣ Hard to build incrementally
‣ Difficult to estimate
‣ Too long… Didn’t read
18
‣ Too technical… Didn’t read
‣ Long time to market cycle
‣ Not always clear who the
users are and what they
expect from the software
‣ Long feedback loops from
users/stakeholders
‣ Acceptance criteria is:
everything is implemented
‣ Hard to maintain
19. SCRUM
USER STORIES TO THE RESCUE
‣ Yes, the are still a requirements document, but they are:
‣ provide context -> alignment
‣ end user/customer language, easy to understand
‣ focus on delivering value
‣ user/customer centred
‣ small, cheap
‣ easily priorizable and repriorizable
‣ versatile
‣ switch the focus to communication instead of specification
‣ shortens time to market
19
20. SCRUM
DEFINING A GOOD USER STORY
‣ Follows the invest
‣ Defines conditions for satisfaction (in DOD)
‣ Defines conditions for readiness (in DOR)
‣ Uses the customers language
‣ Has the whom the what and why
‣ Everyone participates in defining/refining
20
22. SCRUM
USER STORY FORMAT EXAMPLES
‣ As a user, I can backup my entire hard drive. —> wrong,
too large for an agile team to complete in one iteration
‣ As a power user, I can specify files or folders to backup
based on file size, date created and date modified.
‣ As a user, I can indicate folders not to backup so that
my backup drive isn't filled up with things I don't need
saved.
22
25. SCRUM
I.N.V.E.S.T
‣ I for independent - ok… maybe, some dependency
‣ N for negotiable
‣ avoid implementation details - it says the what, not the how
‣ its not carved in stone - until its a part of an iteration it can
still be rewritten
‣ V for value - provide value to your customer with every user
story
‣ E for estimable - otherwise you can’t know when it will be
done (or if it will ever be…)
25
26. SCRUM
I.N.V.E.S.T
‣ S for size
‣ If it’s too big, split it (learn how)
‣ If it’s to small, maybe it’s not a user story
(micromanagement!)
‣ T for testable - if it’s not worth testing it… is it worth
writing it?
26
27. SCRUM
NOT EVERYTHING IS A USER STORY
‣ The process context:
‣ Definition of Done (DOD)
‣ Definition of Ready (DOR)
‣ Non functional requirements:
‣ Requirements that extend through the whole project
27
28. SCRUM
USER STORY SMELLS
‣ Too much detail or too little detail
‣ No conditions of satisfaction
‣ A story that doesn’t deliver value
‣ Technical tasks masqueraded as user stories
‣ Skipping the conversation
28
29. SCRUM
THEME, EPIC, STORY & TASK
‣ Theme - is the highest level of the story hierarchy and
describes a view of a tangible product or an abstract goal
‣ Epic - organise the work needed to complete parts of a
theme into smaller, more manageable pieces.
‣ Story - An epic can have one or more stories, but a story can
belong to only one epic at a time. A story should be small
enough to be completed in one sprint.
‣ Task - A scrum task might require between four and twelve
hours to complete. Team members volunteer for tasks based
on their skills and track the hours remaining on a daily basis.
29
31. SCRUM
STORY POINT
‣ The estimated effort required to complete a story is
measured in story points, with more points being
assigned to stories requiring more effort.
‣ Story points are arbitrary measurements of the effort
(not necessarily the time) required to complete a story,
based on the estimates of scrum team members.
31
32. SCRUM
SCRUM POKER
‣ Scrum poker is a consensus-based, gamified technique for
estimating, mostly used to estimate effort or relative size of
development goals in software development.
‣ In planning poker, members of the group make estimates by
playing numbered cards face-down to the table, instead of
speaking them aloud.
‣ The cards are revealed, and the estimates are then discussed.
‣ By hiding the figures in this way, the group can avoid the
cognitive bias of anchoring, where the first number spoken
aloud sets a precedent for subsequent estimates.
32
33. SCRUM
SCRUM POKER
‣ The cards in the deck have numbers on them. A typical
deck has cards showing the Fibonacci sequence
including a zero: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89;
‣ The reason for using the Fibonacci sequence is to
reflect the inherent uncertainty in estimating larger
items
33
34. SCRUM
SPRINT
‣ Each sprint has very specific, measurable, attainable
goals
‣ Sprint starts with a planning meeting
‣ Sprint end with a retrospective
‣ At the planning meeting, we commit to an amount of
work
‣ We make cursory plans and assignments
‣ Each day we have a daily scrum meeting
34
37. SCRUM
WHY SCRUM?
‣ It’s simple
‣ It’s un-opinionted
‣ It provides clear measures
‣ Each story is estimated
‣ Over time, we can improve estimates and notice trends
‣ Burn-down & Velocity charts
‣ Keeps team focused
‣ Maintains flexibility
37
38. SCRUM
SCRUM TIPS
‣ Don’t get stuck in process
‣ Don’t get stuck in meetings
‣ Don’t trash the backlog
‣ Do keep trying
38