• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
3. Agile Tour at be2 - Ani Mkrtchyan

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!