5. What is Scrum?
• Scrum:
• Is an agile, lightweight process
• Can manage and control software and product development
• Uses iterative, incremental practices
• Has a simple implementation
• Increases productivity
• Reduces time to benefits
• Embraces adaptive, empirical systems development
• Is not restricted to software development projects
• Embraces the opposite of the waterfall approach…
6. When scrum?
• When requirements are not clearly defined
• When the probability of changes during the development is high
• When there is a need to test the solution
• When the client’s culture is open to innovation and adapts to change
7. Scrum Origins
• Jeff Sutherland
• Initial scrums at Easel Corp in 1993
• IDX and 500+ people doing Scrum
• Ken Schwaber
• ADM
• Scrum presented at OOPSLA 96 with Sutherland
• Author of three books on Scrum
• Mike Beedle
• Scrum patterns in PLOPD4
• Ken Schwaber and Mike Cohn
• Co-founded Scrum Alliance in 2002, initially within Agile Alliance
8. SCRUM
• An agile approach to software development that enables us to focus
on delivering the highest business value in the shortest time
• Allows us to rapidly and repeatedly inspect actual working software.
• Scrum methodology makes progress in a series of “sprints” and it
takes a typical duration of 2 to 3 weeks or a calendar month at most,
• product designing, coding, and testing were performed during the sprint
10/10/2019
12. Sequential vs. Overlap
Rather than doing all of
one thing at a time...
...Scrum teams do a little
of everything all the time
Requirements Design Code Test
13. Scrum Roles
• Product Owner
• Possibly a Product Manager or Project Sponsor
• Decides features, release date, prioritization,
• Scrum Master
• Typically a Project Manager or Team Leader
• Responsible for enacting Scrum values and practices
• Remove impediments / politics, keeps everyone productive
• Project Team
• 5-10 members; Teams are self-organizing
• Cross-functional: QA, Programmers, UI Designers, etc.
• Membership should change only between sprints
14. Activities involved
• Sprint planning meeting: the sprint prioritization, evaluation of
product backlog, the design of sprint goal, created the sprint backlog
tasks from product items and later the estimation of sprint backlog in
hours was judged.
• Product owner does this
• Sprint review:Team conducts this on product
• Sprint retrospective Team conducts retrospective on process
• Daily scrum meetings Scrum master conducts the meeting
10/10/2019
15. Sprint
• Sprint: time-boxed event of one month or less, that serves as a
container for the other Scrum events and activities.
• Sprints are done consecutively, without intermediate gaps.
16. Sprint Planning
• time-boxed event of 8 hours, or less, to start a Sprint.
• serves for the Scrum Team to inspect the work from the Product
Backlog that’s most valuable to be done next and design that work into
Sprint backlog.
• To determine the most important subset of product backlog items to
build in the next sprint, the product owner, development team, and
Scrum Master perform sprint planning
10/10/2019
18. Sprint Planning Meeting
Sprint planning meeting
Sprint prioritization
• Analyze/evaluate product
backlog
• Select sprint goal
Sprint planning
• Decide how to achieve sprint
goal (design)
• Create sprint backlog (tasks)
from product backlog items
(user stories / features)
• Estimate sprint backlog in hours
Sprint
goal
Sprint
backlog
Business
conditions
Team
capacity
Product
backlog
T
echnology
Current
product
19. Daily Scrum Meeting
• Parameters
• Daily, ~15 minutes, Stand-up
• Anyone late pays a $1 fee
• Not for problem solving
• Whole world is invited
• Only team members, Scrum Master, product owner, can talk
• Helps avoid other unnecessary meetings
• Three questions answered by each team member:
1. What did you do yesterday?
2. What will you do today?
3. What obstacles are in your way?
20. Product Backlog
• The requirements
• A list of all desired work on project
• Ideally expressed as a list of user stories along
with "story points", such that each item has
value to users or customers of the product
• Prioritized by the product owner
• Reprioritized at start of each sprint
This is the
product backlog
21. User Stories
• Instead of Use Cases, Agile project owners do "user stories"
• Who (user role) – Is this a customer, employee, admin, etc.?
• What (goal) – What functionality must be achieved/developed?
• Why (reason) – Why does user want to accomplish this goal?
As a [user role], I want to [goal], so I can [reason].
• Example:
• "As a user, I want to log in, so I can access subscriber content."
• story points: Rating of effort needed to implement this story
• common scales: 1-10, shirt sizes (XS, S, M, L, XL), etc.
22. Sample Product Backlog
Backlog item Estimate
Allow a guest to make a reservation 3 (story points)
As a guest, I want to cancel a reservation. 5
As a guest, I want to change the dates of a reservation. 3
As a hotel employee, I can run RevPAR reports (revenue-
per-available-room)
8
Improve exception handling 8
... 30
... 50
24. Sprint Backlog
• Individuals sign up for work of their own choosing
• Work is never assigned
• Estimated work remaining is updated daily
• Any team member can add, delete change sprint backlog
• Work for the sprint emerges
• If work is unclear, define a sprint backlog item with a larger amount of
time and break it down later
• Update work remaining as more becomes known
28. Burn-down Chart
• a chart which shows the amount of work which is thought to remain in a
backlog.
• Time is shown on the horizontal axis and work remaining on the vertical
axis.
• Work remaining in Sprint Backlogs and Product Backlogs may be
communicated by means of a burn-down chart
29. Burn-up Chart:
• A chart which shows the amount of work which has been completed.
• Time is shown on the horizontal axis and work completed on the
vertical axis.
30. Sprint Burndown Chart
• A display of what work has been completed and what is left to
complete
• one for each developer or work item
• updated every day
• (make best guess about hours/points completed each day)
• variation: Release burndown chart
• shows overall progress
• updated at end of each sprint
35. Burndown Example 3
Work being performed, but too fast!
Sprint 1 Burndown
0
10
20
30
40
50
60
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Days in Sprint
18 19 20 21 22 23 24 25 26 27 28 29 30 31
Hours
remaining
36. The Sprint Review
• Team presents what it accomplished during the sprint
• Typically takes the form of a demo of new features or underlying
architecture
• Informal
• 2-hour prep time rule
• No slides
• Whole team participates
• Invite the world
37. Scalability
• Typical individual team is 7 ± 2 people
• Scalability comes from teams of teams
• Factors in scaling
• Type of application
• Team size
• Team dispersion
• Project duration
• Scrum has been used on multiple 500+ person projects
38. Scrum of scrums
The scrum of scrums is a technique to scale scrum up for multiple
teams working on the same product, allowing teams to discuss
progress to on their interdependencies, focusing on how to
coordinate delivering software, especially on areas of overlap and
integration.
Depending on the cadence (timing) of the scrum of scrums, the
relevant daily scrum for each scrum team ends by designating one
member as an ambassador to participate in the scrum of scrums
with ambassadors from other teams.
39. Scalability
This should run similar to a daily scrum, with each ambassador
answering the following four questions:
What impediments have my team resolved since we last met?
What impediments will my team resolve before we meet again?
Are there any impediments slowing my team down or getting in our
way?
Are we about to put something in another team's way?
41. Scrum of Scrums
• To coordinate the activities in all the teams:
• Replication of key roles in each of the teams, such as the PO, ScrumMaster,
and technical lead.
• the alignment of iterations:
• for example, plan the deployment of a new version of the product on a specific date
42. Scrum of Scrums
• To coordinate the activities in all the teams:
• To hold staggered daily meetings
• sequencing the daily meetings so that representatives of each team can potentially
participate in the other teams' daily meetings, to identify dependencies and risks and to
find specific skills.
• fact is to realize that the technique is scalable:
• Creating a Scrum of Scrums of Scrums!
• For example, imagine a project of 100 people.
• In this case, we would have 10 teams of 10 people;
• however, 10 teams are more than the recommended number of 9.
• Then we would create another team taken to a higher level
43. Project Organization - Multiple Teams
• Scrum in a large-scale project
• increase the number of teams in the same location
• the number of teams should not grow too fast
• Best is to start with a single team and after the first sprints have been completed
adding a small number of other teams
44. Project Organization - Multiple Teams
• For creating new teams there are two possibilities:
• Splitting an existing team into new teams and add new members
• Advantage: The required know-how is already available in the team and the team can get
productive faster.
• Drawback: Already working teams are torn apart.
• Adding completely new teams
• Advantage: These existing teams can continue with their work without much disruption.
• Drawback: It will take longer to build up the necessary system-know-how in the new
Scrum Team.
45. Project Organization - Multiple Teams
• Independent from the decision how to add new teams the following
rules should be followed:
• Start with a small number of teams
• Always wait until a foundation is build and the teams have stabilized
• Increase the number of teams in small steps
46. Project Organization – Distributed Teams
• More often communication obstacles
will occur and special care has to be
taken to introduce and involve all
team members adequately.
• New team members could e.g.
team, preferably even
temporarily added to an existing
in another
location.
• With this approach the know-how is
transferred and personal relationships
with people in other teams
locations
and
build.
47. Virtual Teams-Distributed environment
• Another possibility for distribution is that the
team itself is spread over multiple locations.
• Called a "virtual team".
• Challenge:
• Ensure good communication between the team
members since some people might not be able to
physically participate in meetings or have no access to
"communication helpers" like the Sprint Board
• Collaboration tools can be assisted
• video conferencing
48. Scrum Product Owner Team
• Proper communication between the Scrum Product Owner and the
team is crucial for successful implementation of the project
• multiple Scrum Product Owners working together to ensure availability
• Ideally there is one dedicated Scrum Product Owner per team.
49. Scrum Product Owner Team
• One of the Scrum Product Owners should be assigned the role of the
'Chief Scrum Product Owner' who is responsible to ensure that the
product is developed in a coordinated fashion.
• For complete Requirement engineering:
• Add other roles and stakeholder like architects or customer representatives
• All Scrum Product Owners should work within a single Scrum Product
Backlog containing all stories relevant for the project.
50. Component or Feature Teams
• When distributing work we can slice the teams in different manners:
as
• Component teams: Each team is only responsible for the implementation of
dedicated components in the system.
• Feature teams: Fully responsible for implementation of user stories as
contained in the Scrum Backlog
51. Component Team
• To finish a user story it is in most cases necessary
to split the stories into smaller pieces that could
be implemented within a single component.
• The resulting dependencies between the teams make
integration on a regular base necessary.
• In many cases a single user story cannot be
finished within a single sprint as implementation
in one team depends on the results of other
stories in other team that are not yet available.
• This is called "Pipelining" and should be avoided as far
as possible.
52. Component teams
• Advantage: It is easier to ensure proper architecture of the system
• Disadvantage: People specialize only on small parts of the system and
knowledge about the system as a whole might get lost.
• Without this knowledge local optimization might take place since the team
might sometimes make decisions that are optimized for the single component
but better solutions from a system perspective could have been made.
53. Feature Teams
• The team is no longer sliced along system
components but implement everything what is
necessary to finish the story.
• Feature teams have to be interdisciplinary and
ideally can act completely autonomous.
• Advantage: System-knowledge is spread and
integration is easier.
• Disadvantage: More difficult to ensure
consistency of the system architecture and it
might be difficult or takes time to ensure that
enough knowledge is available in all teams.
54. Component and Feature Teams
• In reality many larger projects use both: dedicated
Component teams and Feature teams
• Team C is a Component team and provides necessary
infrastructure services to the other teams that are
used as Feature teams.
• Team C does not directly implement user stories but
get the requirements from the user stories
committed by the Feature teams.
• This allows minimizing the number of required
people with expert knowledge (e.g. databases know-
how).
