3. Agile Tour at be2 - Ani Mkrtchyan
Upcoming SlideShare
Loading in...5

3. Agile Tour at be2 - Ani Mkrtchyan






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds


Upload Details

Uploaded via as Adobe PDF

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

3. Agile Tour at be2 - Ani Mkrtchyan 3. Agile Tour at be2 - Ani Mkrtchyan Presentation Transcript

  • Confidential 10/7/2013 1 AGILE TOUR YEREVAN 05, October, 2013 Succeeding with SCRUM at be2 Ani Mkrtchyan (Scrum Master)
  • Agenda 2  Introduction  Getting started with SCRUM  Scrum in Details  Roles  Artifacts  Ceremonies  User Stories  How to estimate? (Planning Poker)  Succeeding with SCRUM at be2  Creating an Effective Product Vision  Building Quality In  INVESTing into good User Stories  How to make SCRUM work?
  • Getting started with SCRUM 3 SCRUM is a simple “Inspect and Adapt” Agile framework that has three Roles, three Ceremonies, and three Artifacts designed to deliver working software in Sprints • Product Owner • Scrum Master • Development Team 3 Roles3 Roles • Sprint Planning • Sprint Review • Daily Scrum Meeting 3 Ceremonies3 Ceremonies • Product Backlog • Sprint Backlog • Burndown Chart 3 Artifacts3 Artifacts
  • SCRUM in details 4 3 Roles SCRUM Team
  • The Product Owner (PO) 5 • Defines the features • Decides on the release (date & content) • Responsible for the profitability of the product (ROI) • Prepares the Sprint Planning Meeting (SPM) • Prioritizes features according to the market value • Accepts or rejects work results Ultimately responsible for the Product
  • 6 • Is cross-functional of 6 (+/- 2) equal members • Self-organized • Has the right to do everything to reach the Sprint goal • Demonstrates results to the Product Owner • Responsible to deliver a potentially releasable Increment of “Done” product each Sprint The Development Team (TEAM) Ultimately responsible for Product Quality
  • The Scrum Master (SM) 7 • Facilitative role that helps PO and Team in their responsibilities • Removes impediments that are slowing down the Team or the PO • “Shields” the team from external interferences • Ensures SCRUM works Ultimately responsible for “guarding” SCRUM and team self-organization
  • SCRUM in details 8 3 Artifacts
  • Product Backlog (PBL) 9 • Ordered list of everything that is needed in the product • The single source of requirements for any changes • Managed by Product Owner (content, availability, and ordering) • Ordered by value, risk, priority, and necessity
  • Sprint Backlog (SBL) 10 • Product Backlog items selected for the Sprint • Includes a plan for delivering the product Increment and realizing the Sprint Goal • Managed by Development Team
  • Sprint Burndown Chart (BDC) 11 • Shows the remaining time left to complete the planned work till the end of the Sprint
  • SCRUM in details 12 3 Ceremonies
  • Sprint Planning Meeting (SPM) 13 • Product Owner invites the Team to the SPM • SPM is time-boxed to maximum 4h (2 week Sprint) • Product Owner presents Sprint Goal and Product Backlog items starting from the top of the PBL • Team discusses the presented User Stories and asks questions • Team estimates the work of the backlog items, called User Stories • Team Commits to the achievable amount of items Scrum Master Dev Team Sprint Planning Meeting PBL
  • Daily Scrum (DS) 14 • Daily Stand-Up meeting is time- boxed to 15 minutes facilitated by Scrum Master • Only “committed” people are allowed to talk • Every Team member reports to the team on: • What have you done since yesterday? • What you will finish by tomorrow? • What impediments you got on your way? Daily Scrum
  • Scrum of Scrum (SoS) 15 • SoS meeting is time-boxed to 15 minutes facilitated by Scrum Master • The frequency for scrum of scrums meetings should be determined by the team • One team member from each team is representing his or her entire team and reports to the rest on: • What has your team done since we last met? • What will your team do before we meet again? • Is anything slowing your team down or getting in their way? • Are you about to put something in another team’s way?
  • Sprint Review Meeting (SRM) 16 • At the end of every Sprint the Team invites the PO to the SRM • SRM is time-boxed to maximum 4h (2 week Sprint) • Team demonstrates on the real Product the feature implemented during the Sprint and asks PO to accept it • PO either accepts or rejects feature Sprint Review
  • Sprint Retrospective (Retro) 17 • Second half of SRM team performs self-assessment • Team applies “Inspect & Adapt” loop to figure out: • What went well? • What went wrong? • What key changes are we going to apply at the next Sprint? Retrospective
  • User Stories (US) 18
  • User Stories (US) 19 As a user I want to login so that I am able to use services on the website. Acceptance Criteria (AC): • - I am able to login using my credentials; • - If I enter wrong credentials I am not able to login and error message is displayed
  • How to estimate? 20 Find a Baseline!
  • Planning Poker Game 21
  • 22 Succeeding with SCRUM at be2
  • 23 Creating an Effective Product Vision
  • 24 Goal:  To gain insight on the possible release dates and manage and prioritize product scope (PO)  Share product roadmap with teams and make sure that entire team understands direction, goals and vision of the product team Format:  RPSs are usually planned outside of a sprint (2 days) to guarantee 100% clear mind and focus;  PO prepares items (themes), writes them down on cards and sticks them to the wall in the conf. room by product areas;  PO presents the items to team and team estimates them with planning poker. Outcome:  Shared clarity about the product future. Roadmap Planning Sessions
  • Roadmap Planning Sessions 25
  • Building Quality In 26
  • Release Postmortems (aka Bug Retrospectives) 27 Release postmortems are regular retrospective-format meetings focused on reviewing and understanding reasons for important bugs popped up after LIVE releases and serve as decision making for preventive actions + follow up to the actions agreed. Goal:  improving overall quality of software releases Means:  Analyze missed bugs / incidents occurred case per case (bug by bug, incident by incident);  Find root causes for the bugs missed (appear live after deployments);  Put preventive actions in place (fix the cause not the effect);  Understand overall defect rates trends (same, worse, better).  Attendees: release management team
  • INVESTing into good User Stories 28 • Immediately actionable • Negotiable • Valuable • Estimable • Sized to fit in • Testable
  • Backlog Grooming Sessions 29  Backlog Grooming Sessions (BGSs) are regular meetings that are held between Product and IT and are driven by PO.  Goal: be there earlier  Means: by preparing better for future
  • Backlog Grooming Sessions 30  To have Less:  Unknowns;  Stressful and long SPMs with “surprises”;  Questions and impediments during the sprints;  Unplanned tasks;  Technical ad-hoc decisions on the go;  To have More:  Time to think & prepare (solutions, correct estimations, planning, …);  Shared clarity on the future;  Granular, INVEST stories by SPM;  Value delivered;  Identify problems...  Estimate stories… BGSs can be any combination of activities to:  Look further…  Shape stories …  Break stories down …  Improve stories…  Clarify details of the stories...
  • How to make SCRUM work? 31 So what do we need to get SCRUM going well? … 5 things!
  • 33 FOCUS
  • 34 TRUST
  • 36 COURAGE
  • Some guys that do SCRUM 37
  • 38 In order to succeed, your desire for success should be greater than your fear of failure. Bill Cosby
  • 39 Q&A
  • 40 Thanks for your attention!