• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Scrum Introduction

Scrum Introduction






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • Indeed.com searches millions of jobs from thousands of job sites.This job trends graph shows the percentage of jobs we find that contain your search terms.RUP - Rational Unified ProcessCapability Maturity Model (CMM) and CMMICMM is being replaced by CMMI == Capability Maturity Model Integration
  • SCRUM方法論的用語很多是套用英式橄欖球術語,如果對橄欖球規則稍有涉獵,應該就有助於SCRUM的了解;SCRUM是指雙方爭球,如下圖,暗喻團隊合作的精神。Agile的一個分支ScrumXPKanbanLean software developmentI think we should run as a startup, using Kanban
  • PO is PMThe Product Owner writes (or has the team write) customer-centric items (typically user stories), prioritizes them, and adds them to the product backlogScrum is facilitated by a ScrumMaster, who ensures that the Scrum process is used as intended.
  • A very simple DoD might include the following:Code CompleteUnit Test completeFunctional / UI Test CompleteApproved by Product Owner
  • Sprint 0
  • 不是幹譙大會,不討論誰做錯
  • Gourmet 美食

Scrum Introduction Scrum Introduction Presentation Transcript

  • Agenda  What is Scrum  Dive into User Story
  • Job Trends
  • What is Scrum
  • What is Scrum Scrum is an agile process that allows self organizing teams to focus on delivering the highest business value in the shortest time.
  • Scrum Process
  • Scrum Lifecycle
  • Scrum Roles  Stakeholder  The stakeholders are the customers, vendors.  They are only directly involved in the process during the sprint reviews.  Product Owner  Creates and prioritizes the product backlog  Understands the customer’s needs and the business value  Scrum Master  Organizes the process  Keeps track of the teams progress  Removes obstacles from the path of the team  Scrum Team Member  Organizes itself to perform the work and deliver business value
  • As a QA in Scrum  Building Test Cases  Participate In Estimating Stories  Help Keep Vision And Goals Visible  Collaborate With Customers And Developers  Provide Fast Feedback  Automate Regression Testing  Participate In Release Readiness/Demos  Enforce the Definition of Done
  • As a QA in Scrum  QA tasks are included on every sprint, and your sprint is not successully completed unless all QA tasks for that sprint are completed or  QA always runs a sprint behind development, in which case QA's testing tasks for sprint 1 are done while devs work on sprint 2.
  • Product Backlog  Used to determine the work for the next sprint  A prioritized list of everything needed or wanted for the entire product  Often written in the form of user stories  Have estimates associated with them (often Story Points)
  • Product Backlog Phase  The Product Owner compiles the requirements  The requirements is broken down into segments  Each segment should be part-deliverable and add business value to the product  The Product Owner personally creates a prioritized list  The list reflect the order in which the items should be delivered. This order can change over time.
  • What is a Sprint  Scrum projects make progress in a series of sprints  Target duration is pre-decided. Scrum suggests 2 weeks to one month.  Scope does not change within a sprint.  In the beginning of each Sprint, the Product Owner freezes the foremost items on the list and summons the Scrum Team to a meeting
  • Sprint Backlog  List of tasks that are to be completed in a sprint  The tasks are created by breaking down the stories during the planning meeting  Have estimates (often in hours) associated with them
  • Sprint Backlog Phase  The first day of the Sprint is reserved to create a Sprint Backlog  Created from the frozen items of the Product Backlog  When the tasks and required time has been determined, the Product Owner lets go.  As of now the Scrum Team works under its own responsibility in a time box
  • Daily Scrum  Every day at the same time  Everyone stands - it helps keeping the meeting short  Anyone can attend, but only the team may speak  Each participant should answers 3 questions  What have you done since yesterday?  What will you do today?  Is there anything preventing you from doing what you have planned?
  • Agile Board in Jira
  • Burndown Chart
  • Demo and Evaluation  The Sprint ends with a demonstration during which functioning software is run before a larger group  Consisting of, besides the Product Owner, users and representatives from management as an example.  This is the basis for an Evaluation Meeting that in turn is the starting block for the next Sprint
  • Retrospective  All team members reflect on the past sprint  Make continuous process improvements  Two main questions are asked in the sprint retrospective  What went well during the sprint?  What could be improved in the next sprint?  Two-hour time limit  This meeting is facilitated by the ScrumMaster
  • Myths about Scrum  Scrum means no documentation  Scrum means no plan  Scrum is easy  Scrum is a silver bullet solution to solve any problem  Scrum is only for team players  Scrum doesn't need up front design  We're doing scrum so we don't need to do TDD, Refactoring Pair Programming, etc.
  • Dive into User Story
  • User Story  As a role  I want something  [so that I get a benefit]  As a User  I want to login  so that I can access personal data on the website
  • More Examples  As a student, I can find my grades online so that I don’t have to wait until the next day to know whether I passed.  As a book shopper, I can read reviews of a selected book so that I can decide whether to buy it.  As a user, I want to search for my customers by their first and last names.
  • Good User Stories  Focus on the user  Keep your stories visible  Use stories to facilitate a conversation with the team and with the users  Keep your stories simple  Progressively decompose your stories  Don’t forget the acceptance criteria  Consider grouping user stories into themes
  • Well-formed User Stories  I – Independent  N – Negotiable  V – Valuable  E – Estimable  S – Small  T – Testable
  • Counterexamples  As Product Owner, I want a list of highly- rated restaurants on the website.  Drawbacks: It’s not only about you!  Better: Focus on your end users and stakeholders. “As a gourmet tourist, I want a list of highly-rated restaurants on the website.”
  • Counterexamples  Write game rules.  Drawbacks: not independent, no business value, not small.  Better: “As a newbie game player, I want to know who goes first so we can start the game.”
  • Non-functional Requirements  Reliability  Availability  Portability  Scalability  Usability  Maintainability  Security  Performance  Robustness
  • Non-functional Requirements Think of non-functional requirements as constraints  As a customer, I want to be able to run your product on all versions of Windows from Windows 95 on.  As a user, I want the site to be available 99.999% of the time I try to access it so that I don't get frustrated and find another site to use.  As the CTO, I want the system to use our existing orders database rather than create a new one sot that we don't have one more database to maintain.
  • Reference  Use cases - User Stories: so precious but not the same !  Non-functional Requirements as User Stories
  • Questions?