Extra stuff Flashcards

(91 cards)

1
Q

Transparency leads to…

A

Inspection

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

Developers are accountable for…

A

-Creating plan for Sprint backlog
-Instilling quality by adhering to DOD
-Adapting plan each day towards Sprint Goal
-Holding each other accountable as professionals

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

PO is also responsible for…

A

Ordering the Product Backlog

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

Sprint must have these things

A

-No changes are made to endanger the Sprint Goal
-Quality does not decrease
-Product backlog is as refined as needed
-Scope of the Sprint goal may be classified and renegotiated with the product owner if more is learned

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

Advantages with refinement

A

Increase confidence and understanding

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

Sprint review

A

Inspect outcome of Sprint
Determine future adaptations
Present work and with stakeholders progress towards product goal is discussed

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

Use of scrum artifacts

A

Help create transparency, so you can adapt from same point

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

Why commitment of artifacts

A

Provides information to enhance transparency and focus
Can measure

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

Refinement

A

Can split into smaller, more manageable items
-especially since an item should able to be completed within a sprint

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

When is an item ready?

A

When it can be completed within a sprint
-sometimes there are prerequesits until you can do an item or else it will take to long
-remember: increments are usable value

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

User Story

A

PO use to define features of the system from a user perspective
More detail in acceptance criteria

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

Example of user story

A

“As a <Insert>, I want to <Something>”</Something></Insert>

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

Keywords for user stories

A

Epic
User story

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

Epic

A

Giant user story that has been cut down into substories to be created during a single sprint

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

The 3 C’s

A

Card
Conversation
Confirmation

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

Card

A

User story
Gives an idea of what the story is about

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

Conversation

A

Discussion you have about the user story which gives a better ideas as to what it is about
What is said here is more important that what is written
-User stories are supposed to start discussions

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

Confirmation

A

Series of acceptance criteria added to the card

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

INVEST

A

Independent
Negotiable
Valuable
Estimable
Small
Testable

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

Example of Software quality

A

(Availability) The sales portal shall be available to the users 99.9% of the time every month during business hours

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

One way of defining category

A

putting everything under one of these 5 categories:

effectiveness, efficiency, satisfaction, safety, usability

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

Other way of defining category

A

Functional Stability
Performance Efficiency
Compatibility
Usability
Reliability
Security
Maintainability
Portability

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

MatBlazor

A

Material design components for blazor

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

Fun fact about Blazor

A

Normally c# is serverside language, but blazor is clientside aswell

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Webassembly
Clientside instead of serverside Quicker response
26
Our Sprint Planning
Assess spillover from last sprint PO addresses new PBI's and Q&A Set Sprint goal PO leaves and we assess PBIs to include Refinement (new) Create subtasks Delegate tasks
27
SBIs before
PBIs and SBIs were same thing but now SBIs are smaller tasks created from PBI
28
Our Sprint Review
Demo with PO and maybe stakeholder Some feedback PO left and we would assess if SBIs were finished or not
29
Old retro
Starfish -start, more of, keep, less of, stop Template Developers host meeting No action points were actually implemented
30
Henning retro
Start, keep stop (we have used this since) Looking at past action points
31
Your daily scrums
used to do demos, that is why length Explain complex technical things Now its only important stuff to move forwards and techincal understanding is seperate
32
Not scrum stuff with review
Not much inspection with PO
33
Not scrum stuff with daily
Sprint goal was basically never used, only Sprint backlog
34
Not scrum stuff with planning
The only difference between SBI now is that it is no longer in the product backlog
35
Complex
Enabling constraints Loosely coupled Probe-sense-respond Emergent Practise Unknown unknowns Your actions change the situation in unpredicatble ways
36
Probe-sense-respond
Do shit until something works since you dont knwo what will work
37
Complicated
Governing constraints Problems are tightly coupled Sense-analyse-respond Good practise Known unknowns Work rationally towards a decesion
38
When to use agile and scrum
complex
39
Chaotic
Lack of constraint De-coupled Act-sense-respond Novel Practice
40
Clear
Tightly constrained No degrees of freedom Sense-categorise-respond Best practise (rules in place) Know knowns Dont force into this situation by oversimplifying -becomes chaotic if complacent
41
Sense-categorise-respond
Establish the facts Categorize Respond by following the rule or applying best practice
42
Sense-analyse-respond
Access the facts Analyse Apply the appropriate good operation practise
43
What is agile
Philosophy/Mindset/Culture Adaptive approach to development Agile Manifesto
44
What should you focus on in agile
Deliver the highest value features first -50% of features aren't used
45
Iterative
vague idea to realization “iterating” builds a rough version, validates it, then slowly builds up quality
46
Incremental
Incrementing calls for a fully formed idea “incrementing” builds a bit at a time
47
act–sense–respond
act to establish order; sense where stability lies; respond to turn the chaotic into the complex
48
Why is agile not incremental
Only knows whole scope from start due to analysis and design, making it slighly iterative
49
Risk with iterative
Start working with entire scope from beginning Risk in software delivery
50
Agile is...
Iterative and incremental Increments adds new things, but each sprint also refines previous things
51
Agile vs waterfall
100% done with certain slices of code compared to nothing really done -cant be delivered In waterfall, plan creates cost/schedules estimates In agile, vision creates feature estimate
52
scrum is...
Simple to understand, difficult to master
53
Why is scrum difficult to master
Change is hard Reviews can be scary More collaboration might seem slower -many meetings
54
Product
Vehicle to deliver value Clear boundary Known stakeholders Well-defined users or customers
55
What problem do stories address
Software requirements are a communcations problem
56
Business dominates
functionality and deadlines are prioritised over developers' understanding
57
Developers dominates
technical jargon replaces stuff business people can understand -cant learn from listen -cant communicate their wants properly
58
If developers responsible for resources
may trade quality for additional features may only partially implement a feature may solely make decisions that should involve business
59
If business is responsible of resources
lengthy unfront requirements negotiation features are progressively dropped when deadlines near
60
imperfect schedules
users come up with new ideas too many intangibles developers are bad at estimating To combat this - make decisions with what we know often
61
details in user stories
can be acceptance criteria -e.g. if you can get a refund or not
62
Theme
Collection of related user stories
63
Independent
Standalone PBI
64
Story writing workshops
Entire team + some stakeholders maybe Not every sprint Generate stories together -as many as possible No prioritisation Start with epic then reiterate
65
Why stories
Easier to remember Right size for planning Can iterate (make smaller) Support opportunisitic development Participatory design
66
opportunisitic development
design solutions by moving opportunistically between top-down (breaking down) and bottom-up (piecing together) approaches
67
Participatory design
actively involve all stakeholders in the design process to help ensure the result meets their needs and is usable
68
Software quality
Capability of a software product to satisfy stated and implied needs when used under specific conditions Degree to which a software product meets established requirements Series of categories that software criteria can be placed under to enhance readability
69
Good software should...
maintanable, usable and dependable
70
2 main approaches to Software Qualities
Defect management approach Attributes approach
71
Defect management approach
any failure to address end—user requirements
72
Attributes approach
Follows fixed taxonomies or quality models
73
Advantages with attributes approach
-helpful for getting an overall understanding of software quality Guide the development of the product
74
Your non-functional requirements
Security Usability Convenience
75
Where to find NFRs
DOD
76
Release date?
PO decides Along with the content of product
77
Extra thing about self-managing
No titles
78
When do you change membership?
Between sprints
79
Sprints definition
Where progress is made Where the product is designed, coded and tested Fixed length periods of work
80
What should be considered in the sprint planning
High-level design You also break tasks into subtasks
81
What are daily scrums not for
Status for the SM and PO Not for problem solving -adjust upcoming planned work, not solving issues
82
Advantages with story pointd
Additive Help avoid problems with unit confusion
83
Is work assigned?
No, it is pulled from the backlog
84
Who can edit the sprint backlog
Any team member
85
A good plan is...
One that supports reliable decision-making
86
When is velocity useful
Over at least a handful of iterations
87
Fixed-date project
Use scope range "by that date you will have these fearures and some of these"
88
fixed-scope project
Use date range "it will take this amount of time to deliver these features"
89
Environment of scrum
PO orders work for a complex problem into PB ST turns work inot increments of value Team + stakeholders inspect and adjust repeat
90
scrum is built upon...
the collective intelligence of the people using it
91
is scrum instructions?
no it guides their relationships and interactions