Exercise 2 SCRUM Flashcards
1
Q
Defined Process Control Model
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.
2
Q
Empirical Process Control Model
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.
3
Q
Scrum is based on an Empirical Process Control Model
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.
4
Q
SCRUM Artifacts
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
5
Q
Scrum Meetings
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)
6
Q
Scrum Team
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
7
Q
Sprint - Definition
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.“
8
Q
Sprint Characteristics
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
9
Q
Product Backlog
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
10
Q
Priority
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
11
Q
Example for backlog items: User Stories
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
12
Q
Properties of a good user story: INVEST
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
13
Q
User Story Template
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
14
Q
Acceptance Criteria
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.
15
Q
Definition of Done
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
