Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Software Engineering > SWE II: SCRUM > Flashcards

SWE II: SCRUM Flashcards

1
Q

Software + Engineering

A

Software: the invisible language that whispers stories of possibility to the hardware

Engineering: “Creative application of scientific principles to design, develop, machines, structurs, processes, or work utilizing them singly or in combination.

  • Design: intentional solution to a problem given its contraints
  • Construction: planning, monitoring, controlling the activities to achieve a solution, + tools and techniques
    • for SW:
      • Effort estimation
      • planning development and release
      • day-by-day practices
      • customer relationship
      • quality assurance
      • acquisition
  • Operation: conduction of the solution and adaptation, within its limits
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Agile manifesto - values

A

Individuals and interatction > processes and tools

Working software > comprehensive documentation

Customer collaboration > contract negotiation

Responding to change > following a plan

In practice:

  • tight collaboration between developers and stakeholders over the entire duration of the project.
  • self-organizing teams
  • SCRUM is the most used methodology today, Kanban and eXtreme Programming are less in vogue
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

SCRUM

A
  • User stories
  • estimation
  • planning
  • tight feedback loops
  • reflection
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Software Quality

A

Quality is a key component in any engineering practice.

In SWE:

  • SW analytics allow measuring and controlling SW projects
  • Code smells indicate possible problems
  • Technical debt
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

SCRUM def.

A

An ordered formation of players used to restart play in rugby.

Also a team-based framework to develop complex systems and products.

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

Why SCRUM?

A
  • Old sequential approach doesn’t work in today’s fast-paced, competive world => speed and flexibility are essential.
  • Using a holistic method seems to work better (from rugby), with 6 characteristics
    • instability is factored in
    • self-organizing project teams
    • overlapping development phases
    • “multi-learning”
    • subtle control
    • organizational transfer of learning
  • The above allow to have a fast and flexible process.
  • As a new approach can act as a change event to introduce creative (market-driven) ideas and processes into an old, rigid org.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Agile Development Principles

A
  1. Test as you go
  2. Deliver product early on and often, and work on the feedback given
  3. Document as you go, only as required
  4. Build cross-functional teams
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Theoretical foundations of Agile SW Dev.

A
  • Empirical Process control theory
  • Iterative and incremental approach:
    • optimizes predictability
    • controls risk
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

SCRUM pillars, and relative events to adhere to them

A
  • Transparency: Process visible to whom is responsible
  • Inspection: On artifacts and objectives to detect differences
  • Adaptation: to meet goals

This are respected using:

  • Sprint planning
  • Daily scrum
  • Sprint review
  • Sprint retrospective
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

SCRUM process

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

SCRUM roles

A
  • Product owner
  • Scrum master
  • Team member

These 3 are committed to the project (Pigs), other parties are just involved (end-users, stakeholders)

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

SCRUM Product owner

A
  • Controls priority order of items in the backlog:
    • Interacts with stakeholders to deliver max. (business) value
      • What needs to be built and when
  • Ensures the team understands the needs of end-users: knows requirements, and is available to answer team questions
    • Creates acceptance criteria for stories
    • Knows customers
  • Responsible of staying true to the product vision: keeps in mind who’s the product built for, why, and its intended use.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

SCRUM Master

A
  • Coach: with goal of making team self-organizing
    • Facilitator, not a boss (SCRUM expert, good shepherd, guardian)
  • Adjust itself to the team experience: steps back when the teams starts to self-manage
  • Removes impediments for the team (Impediment bulldozer)
    • External (escalates issues to relevant people, help solving issues (e.g. HW))
    • Internal (Helps the team see problems, encourges them to find solutions)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

SCRUM Team member

A
  • The team is self-organizing: they decide tools, techniques and how to assign tasks.
  • Team member estimate the effort required for a stories/feature/tasks
  • Team size: from 5 to 9
    • Has enough variaty of skills
    • Communication overhead must be low
  • Cooperate to get to the goal
  • Willing to work outside comfort zone if the team needs it

SCRUM team: P. owner + SCRUM master + team mambers

Team: SCRUM team - P. owner - SCRUM master

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

Scrum Sprint

A
  • Sprint
    • Sprint planning
    • Spring Backlog
    • Effort estimation
    • Story Time
    • Daily SCRUM
    • Sprint Review
    • Retrospective
    • Abnormal sprint termination
  • Release planning
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

SCRUM Sprint

A
  • Basic iteration
  • Produces piece of working SW to be demonstrated and reviewd at the end of the sprint.
17
Q

Sprint plannin

A
  • What and how we’ll do it?
    • What:
      • committed stories
      • product owner proposes story, team members decide wheter to commit it
    • How
      • Decompose stories into tasks
      • max effort per task: half-day
18
Q

Sprint Backlog

A

List of stories and tasks related to those stories.

Stories/tasks are estimante using hours, point and task count.

19
Q

Effort estimation

A

Essential to define a predictable schedule.

Relative vs. absolute estimates

  • Relative are easier
  • Stories are estimated using points (fibonacci series)
  • After a sprint is completed an estimate of how many stories can be completed in a sprint is computed (i.e. velocity, that is not a perf. measure)
20
Q

Estimation analogy to shopping

A

Items => stories

prices => estimates

budget => progress

constraints => business/technological constraints

21
Q

Estimation Game

A
  • Part 1: team members take turns, inserting new stories and ordering them based on their (estimated size)
  • Part 2: team members take turns placing fibonacci cards above stories, they can move stories around as before.
22
Q

Estimation poker

A

Every team member picks a card at the same time

High and low cards discuss their rationale.

Consensus achieved with feedback with the product owner.

23
Q

Story time

A

Team meeting in which backlog is refined / groomed:

  • reviewing upcoming stories
  • estimating future stories
  • clarification of requirements
  • splitting stories

The goal is to start the next sprint with a set of small and well-understood stories (already defined/sized).

24
Q

Daily SCRUM

A
  • Daily: any time every member is available
  • Small: only developers
  • brief: keeping everything up-to-date, standing, maximum 15 minutes
  • Pointed:
    • what has been done
    • what will be done
    • current obstacles
25
Q

Sprint review

A

Goal:

  • Demo of some piece of working SW.
  • Report on incomplete stories
  • Transparency
  • Record reaction of stakeholders
    • product owner will base their decision on these
    • no planning here.
26
Q

Retrospective

A
  • Goal: identify a few things to improve and define a relative action plan.
  • What:
    • What happened? Artifacts produced? In how long?
    • decide what to do: to improve team perfomance for the next sprint (must be under control of the team)
    • generate insights: understand causes, no finder pointing
    • Focus on lesson learned and how they can be applied to next sprint
27
Q

Release planning

A

The goal of Release Planning is to when various sets of usable functionality or products will be delivered to the customer which to enable the Scrum Team to have an overview of the releases and delivery schedule for the product being developed.

Modes:

  • Fixed scope
  • Fixed date
  • Fixed scope & fixed date

Scrum is no silver bullet: adding manpower to a late SW project makes it later.

28
Q

SCRUM artifacts

A
  • Product Backlog
  • Product Backlog Item / Story
  • Epic
  • Sprint Backlog
  • Burndown chart
29
Q

Product backlog

A
  • Anything that will consume team’s resources is here
  • Ever changing
  • String story ordering
  • Property of the product owner
  • Can be digital or physical (spreadsheet/wall)

Properties of a good backlog => DEEP:

  • Detailed appropriately
  • Estimated
  • Emergent
  • Prioritzed
30
Q

Product Backlog Item / Story

A
  • Is (INVEST)
    • independent
    • negotiable
    • valuable
    • estimable
    • small
    • testable
  • Has:
    • essential description:
      • As a I want so that
    • Acceptance criteria: written by PO and easy to turn into (automated) tests
31
Q

Aspects of a user story

A
  • Card: essential description, then extended with notes
    • promise for a convo.
  • Conversation:
    • involves: dev. team, PO, customer, other stakeholders
    • Done in estimation, when selected to implement, when divided in subtasks, during impl., in retrospective
  • Confirmation: satisfaction conditions, defined in conversations, recorded as acceptance tests, “definition of done”
32
Q

Epic

A

A piece of requirement that is too large for a single story, needs to be split into stories.

33
Q

Sprint Backlog

A
  • Set of committed stories and relative tasks (that may change during sprint, the tasks).
  • Additional tasks for example: bug fixing, team improvement, research work, perf. and security
  • Frozen after the sprint planning
  • Managed by the TEAM
34
Q

Information radiators

A

Burn down chart (residual work units, sprint, release)

Burn Up chart (completed work units)

Task board (to do, in progress, done)

35
Q

Definition of done

A

Is a team shared definition that describes a completed story. Typically means that the story is shippable.

  • Code review
  • Design review
  • Refactoring
  • Performance testing
  • Unit tests passed
36
Q

Table of events vs participants vs artifacts vs activities

A

Software Engineering (5 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions