Scrum Flashcards

1
Q

Scrum origins

A
  • Jeff Sutherland
    • Initial scrums at Easel Corp in 1993
  • Ken Schwaber
    • ADM
    • Scrum presented at OOPSLA 96 with Sutherland
    • Author of three books
  • Mike Beedle
    • Scrum patterns in PLOPD4
  • Mike Cohn
    • Co-founder of Scrum Alliance in 2002 with Ken Schwaber
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Charecteristics

A
  • Self organzing teams
  • Product progresses in a series of month-long “sprints”
  • Requirements are captured as items in a list of “product backlog”
  • No specific engineering practices prescribed
  • Use generative rules to create an agile environment for delivering projects
  • One of the “agile processes”
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Agile manifesto

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Project noise level

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Sprints

A
  • Scrum projects make progress in a series of “sprints”
  • Typical duration is 2-4 weeks or a calendar month at most
  • A constant duration leads to a better rhythm
  • Product is designed, coded and tested during the sprint
  • No changes during a sprint!
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Sequential vs overlapping development

A

Rather than doing linear work scrum teams overlap tasks and do a little of each at all the time.

  • Requirements
  • Design
  • Code
  • Test
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Scrum framework

A

Roles

  • Product owner
  • Scrum master
  • Team

Ceremonies

  • Sprint planning
  • Sprint review
  • Sprint retrospective
  • Daily scrum meeting

Artifacts

  • Product backlog
  • Sprint backlog
  • Burndown charts
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Product Owner

A
  • Define the features of the product
  • Decide on release date and content
  • Be responsible for the profitability of the product (ROI)
  • Prioritize features according to market value
  • Adjust features and priority every iteration as needed
  • Accept or reject work result
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

The scrum master

A
  • Represents management to the project
  • Responsible for enacting Scrum values and practices
  • Removes impediments
  • Ensure that the team is fully functional and productive
  • Enable close ooperation across all roles and functions
  • Shield the team from external interferences
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

The team

A
  • Typically 5-9 people
  • Cross-functional
    • Programmers, testers, UX designers etc.
  • Members should be full-time
    • May be exceptions
  • Teams are self-organizing
    • Ideally no titles but rarely a possibilty
  • Membership should change only between sprints
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Sprint planning meeting

A
  • Team selects items from the product backlog they can commit to completing
  • Sprint backlog is created
    • Task are identified and each is estimated (1- 16 hours)
    • Collabroatively, not done alone by the scrum master
  • High-level design is considered
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

The daily scrum

A
  • Parameters
    • Daily
    • 15-minutes
    • Stand-Up
  • Not for problem solving
    • Whole world is invited
    • Only team members, Scrum master, product owner can talk
  • Helps avoid other unnecessary meetings

The three questions

  1. What did you do yesterday?
  2. What will you do today?
  3. Is anything in your way?

These are not status for the scrum master but commitments in front of peers

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

The sprint review

A
  • Team presents what it accomplished during the sprint
  • Typically takes form of a demo of new features or underlying architecture
  • Informal
    • 2-hour prep time rule
    • No slides
  • Whole team participates
  • Invite the world
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Sprint retrospective

A
  • Periodically take a look at what is and is not working
  • Typically 15-30 minutes
  • Done after every sprint
  • Whole team participates
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Start/Stop/Continue

A

Whole team gathers and discusses what they´d like to

Start doing

Stop doing

Continue doing

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Product backlog

A
  • The requirements
  • A list of all desired work on the project
  • Ideally expressed such that each item has value to theusers or customers of the product
  • Prioritized by the product owner
  • Reprioritized at the start of each sprint
17
Q

The sprint goal

A

A short statement of what the work will be focused on during the sprint

18
Q

Managing the sprint backlog

A
  • 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 or 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
19
Q

Scalability

A
  • Typicial individual team is 7 +- 2 people
    • Scalability comes from team of teams
  • Factors in scaling
    • Type of application
    • Team size
    • Team dispersion
    • Project duration
  • Scrum has been used on multiple 500+ person projects
20
Q

Scrum roles

A

Pigs committed

  • Project owner
  • Scrum master
  • Scrum team

Chickens involved

  • Users
  • Stakeholders
  • Consulting experts
21
Q

Definition of “done” (DoD)

A
  • “Potentially shippable product increment”
  • What does it mean?
    • When all code is checked in?
    • Deployed to test environment?
    • Verified by integartion test team?
  • When possible use
    • Ready to deploy to production
  • Most importantly
    • Have a common understanding of DoD that the team and the product owner can agree on
22
Q

Testing & Scrum

A
  • Scrum doesn´t specify any specific engineering practices
  • However each sprint is requiered to produce ready to-use code
    • Heavy in sprint testing is usually applied
    • Some teams have dedicated testers
      • Others have programmers test everything
  • Other engineering practices are up to you
    • Automation, code inspection, pair programming, static analysis tools etc.
23
Q

Stabilization sprints

A
  • Team focuses entirely on defects
    • Prepares a product for release
    • Useful during
      • Active beta periods
      • When transitioning a team to Scrum
      • If quility isn´t quite where it should be on initial release
  • Not part of standard Scrum, just something useful in some cases