Exercise 2 SCRUM

Question 1

Defined Process Control Model

Answer 1

• 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.

Question 2

Empirical Process Control Model

Answer 2

• 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.

Question 3

Scrum is based on an Empirical Process Control Model

Answer 3

• 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.

Question 4

SCRUM Artifacts

Answer 4

• 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

Question 5

Scrum Meetings

Answer 5

• 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)

Question 6

Scrum Team

Answer 6

• 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

Question 7

Sprint - Definition

Answer 7

„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.“

Question 8

Sprint Characteristics

Answer 8

• 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

Question 9

Product Backlog

Answer 9

• 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

Question 10

Priority

Answer 10

• 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

Question 11

Example for backlog items: User Stories

Answer 11

• 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

Question 12

Properties of a good user story: INVEST

Answer 12

• 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

Question 13

User Story Template

Answer 13

• 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

Question 14

Acceptance Criteria

Answer 14

• 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.

Question 15

Definition of Done

Answer 15

• 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

Question 16

Scenarios

Answer 16

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

Question 17

Relation between User Stories, Use Cases and Scenarios

Answer 17

• 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

Question 18

Sprint Planning Meeting

Answer 18

• 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

Question 19

Sprint Review Meeting

Answer 19

• 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)

Question 20

Sprint Retrospective Meeting

Answer 20

• 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

Question 21

Scrum as Methodology

Answer 21

• 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.

Question 22

Summary

Answer 22

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

Question 23

Which of the following roles are NOT part of a Scrum Team?

Select one or more:

a. Customer
b. Project Manager
c. Developer
d. Scrum Master
e. Product Owner

Answer 23

a,b

Question 24

What is NOT a purpose of the project kickoff meeting?

Select one or more:

a. Creation of the Sprint Backlog
b. Creation of the Product Backlog
c. Prioritization of the Product Backlog
d. Delivery of a product increment

Answer 24

a,d

Question 25

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 25

c, g, d