Exercise 2 SCRUM Flashcards

Question

What are the three questions in the Daily Scrum Meeting? Select one or more: a. How long do you need for your task today? b. When can you finish your task? c. Are there any impediments in your way? d. What do you promise to resolve until the next meeting? e. Why did you not work as hard as I did yesterday? f. Why did you create this bug in my module? g. What did you do since the last meeting?

Answer 1

A

Requires that every piece of work is completely understood
Deviations are seen as errors that need to be corrected
Given a well-defined set of inputs, the same outputs are generated every time
Precondition to apply this model:
- All the activities and tasks are well defined to provide repeatability and predictability
If the preconditions are not satisfied:
- Lot of surprises, loss of control, incomplete or wrong work products.

Answer 2

A

Empirical process: An imperfectly defined process, not all pieces of work are completely understood
Deviations, errors and failures are seen as opportunities that need to be investigated
- The empirical process “expects the unexpected”
Control and risk management is exercised through frequent inspection
Condition when to apply this model:
- Change is frequent and cannot be ignored
- Change of requirements, change of technology, change in the organization, people change too.

Answer 3

A

Original definition (from Rugby): A Scrum is a way to restart the game after an interruption
- The forwards of each side come together in a tight formation and try to get the ball when it is tossed in among them
Definition in agile processes: Scrum is a technique that deals with interruptions (change)
- Manages and controls software and product development with rapidly changing requirements
- Improves risk management by improved communication and cooperation and the delivery of product increments.

Answer 4

A

Product Backlog: List of requirements for the whole product
Sprint Backlog: List of requirements and tasks for one iteration (“Sprint”)
Potentially Shippable Product Increment: Release to the Product Owner that contains all results of the current Sprint

Answer 5

A

Project Kickoff Meeting (Start of the Project): Create and prioritize Product Backlog
Sprint Planning Meeting (Start of each Sprint): Create Sprint Backlog
Daily Scrum Meeting (Every Morning,15min): Standup meeting to share status, impediments and promises
Sprint Review Meeting (End of each Sprint): Demonstration of realized backlog items to the Product Owner (and other stakeholders)

Answer 6

A

Development Team
- Self-organizing and cross-functional Realizes the product increment
Product Owner
- Defines the product Responsible for results
Scrum Master
- Resolves impediments Responsible for the process

Answer 7

A

„A time-box of one month or less during which a “Done”, useable, and potentially releasable product increment is created. Sprints best have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.“

Answer 8

A

Typically 2-4 weeks long
Starts with Sprint Planning Meeting
- Create the Sprint Backlog: Selection of items to be implemented in the Sprint
- Important: Development Team and Product Owner select the items together
Ends with Sprint Review Meeting
- Release and deliver the application (product increment)
- Demo of the application during the meeting
- Important: Product Owner gives feedback
Sprint Review Meeting and Sprint Planning Meetings can be combined into a single meeting with the Product Owner
The Scrum Team can additionally perform a Sprint Retrospective Meeting
The Development Team
- Works on the items in the Sprint Backlog

Uses e.g. a Task Board to visualize the status of these items

* The Scrum Master visualizes the progress, e.g. in a Burn Down Chart

Answer 9

A

Collection of items (e.g. user stories, scenarios, etc.) prioritized by the Product Owner
The Product Backlog can always be changed and reprioritized during the projects
Created on the basis of the problem statement during the Kickoff Meeting or in the phase before the actual project starts

Answer 10

A

The priority describes the importance of the requirement for the software to be developed
If the requirement has a high value for the product (e.g. because it is the core functionality of an application), it has a high priority
Examples for a priority scheme (that we also use in JIRA)
- Prio 1 = Critical (Candidates for the first development sprints, must be part of the first  product increment)
- Prio 2 = Major (Must be realized within in the project, can be realized in one of the following   product increments)
- Prio 3 = Minor (Desirable, if there is enough time)
- Prio 4 = No Important
➡ Priorities of requirements can change during the project in Scrum
➡ Prioritization is done by the Product Owner

Answer 11

A

A User Story includes a sentence that describes what the user does or needs
Often written on a card
Users (roles) are the actual   users of the system

Answer 12

A

Independent - avoid overlapping User Stories
Negotiable - A User Story is not a contract, but a basis for a discussion between Development Team and the Product Owner
Valuable - for the user and the business. And Vertical: we plan and develop features and not layers
Estimable - the stories on the Product Backlog represent the basis of our project plan
Small - too large user stories should be partitioned into smaller ones, because the complexity increases over-proportional otherwise
Testable - if a User Story is not testable, it might not be a real value for the product, this also implies realizability

Answer 13

A

As <role>,<br></br> I want to <feature> so that <reason></reason></feature></role>
Main advantages of the template:
Using the “I” phrasing, developer can identify with the given user role
Defines a structure and simplifies the prioritization process
Facilitates categorization according to user roles

Answer 14

A

Conditions that a software product must satisfy to be accepted by a user, customer or other stakeholder
Pre-established standards or requirements a product or project must meet
Acceptance Criteria are a set of statements, each with a clear pass/fail result, that specify requirements applicable at the current stage of project integration
- Functional (e.g. minimal marketable functionality)
- Non-functional (e.g. minimal quality)
These requirements represent “conditions of satisfaction.” There is no partial acceptance: either a criterion is met or it is not.

Answer 15

A

The Definition of Done (DoD) is usually a clear and concise list of requirements that a software Increment must adhere to for the team to call it complete
Until this list is satisfied, a product Increment is not done
➡ Before a piece of functionality is in a potentially releasable state, it must adhere to a common understanding of completion by those working on the Increment
Examples:
- End-User Documentation is updated
- Unit testing is complete and passed
- Developer has peer reviewed code
- Integration Testing is complete and passed
- Configuration Management has added the functionality to the build and captured release notes
- Product Owner has reviewed the demo and approved the User Story
- User Acceptance Testing is complete and passed

Answer 16

A

Instance of a use case. A scenario represents a concrete sequence of interactions between one or more actors and the system.

Answer 17

A

Scenarios are typically created during Analysis
Use Cases and Scenarios typically cover a larger scope and are more formal than User Stories
- Scenarios and Use Cases have participating actors, preconditions, event flow, post condition and special quality requirements
- Scenarios are instantiated use cases
- More details about scenarios and use cases in chapter 4 of Object Oriented Software Engineering using UML by Bruegge and Dutoit
User Stories are usually created during requirements elicitation

Answer 18

A

The Development Team estimates the difficulty for the most important items in the Product Backlog
Development Team and Product Owner select Product Backlog items that can be realized in the Sprint
- The Development Team negotiates with the Product Owner how many items it can realize in the Sprint
- The Product Owner defines when an item is accepted (e.g. using acceptance criteria)
- Important: The Sprint Backlog cannot be changed by the Product Owner within the Sprint to protect the team from too many changes

Answer 19

A

The Development Team delivers a Product Increment including the realized items from the Sprint Backlog
- Deliver the application before the Review Meeting to the Product Owner
The Development Team demonstrates the Product Increment to the Product Owner
The Product Owner (or other stakeholders) gives   feedback and decides whether the items are   realized completely
- Realized items are ticked off in the Sprint Backlog
Unrealized items move back to the Product Backlog
- These are candidates for the next Sprint
- Feedback of the Product Owner (or other stakeholders) is stored in JIRA
The Product Owner can add new requirements to the product backlog or change existing ones
The Review Meeting can include a Sprint Retrospective (can also be a separate meeting)

Answer 20

A

Scrum Master and Development Team meet to discuss how the previous Sprint worked out
The Product Owner can also participate if necessary There are different Retrospective techniques
Often it is most effective to brainstorm about things that worked well and things that did not work well
Each team member is asked to identify specific things that the team should:
- Start doing
- Stop doing
- Continue doing

Answer 21

A

Scrum as Methodology
Involvement of the customer
- Onsite customer (“co-located”)
Planning
- Checklists and incremental daily plans (“Daily Scrum”)
Reuse
- Checklists from previous projects
Modeling
- Models may or may not be used
Process
- Iterative, incremental and adaptive process
Control and Monitoring
- Risk management distributed across daily meetings.

Answer 22

A

Scrum

3 Artifacts: Product Backlog, Sprint Backlog, Potentially Shippable Product Increment
4 Meetings: Project Kickoff, Sprint Planning, Daily Scrum, Sprint Review
3 Roles: Scrum Master, Product Owner, Developer

JIRA Agile

Create and manage the Product Backlog and its backlog items (e.g. User Stories / Scenarios)
Plan the Sprint by choosing backlog items and by adding Sub-Tasks
Track the status of a Sprint using a Taskboard and the progress of a Sprint with a Burn Down Chart
Prioritize and estimate backlog items —> more about estimation in a later exercise
Review the Sprint using acceptance criteria