3. Agile Tour at be2 - Ani Mkrtchyan


Published on

Published in: Technology, Sports
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

3. Agile Tour at be2 - Ani Mkrtchyan

  1. 1. Confidential 10/7/2013 1 AGILE TOUR YEREVAN 05, October, 2013 Succeeding with SCRUM at be2 Ani Mkrtchyan (Scrum Master)
  2. 2. 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?
  3. 3. 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
  4. 4. SCRUM in details 4 3 Roles SCRUM Team
  5. 5. 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. 6. 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
  7. 7. 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
  8. 8. SCRUM in details 8 3 Artifacts
  9. 9. 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
  10. 10. 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
  11. 11. Sprint Burndown Chart (BDC) 11 • Shows the remaining time left to complete the planned work till the end of the Sprint
  12. 12. SCRUM in details 12 3 Ceremonies
  13. 13. 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
  14. 14. 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
  15. 15. 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?
  16. 16. 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
  17. 17. 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
  18. 18. User Stories (US) 18
  19. 19. 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
  20. 20. How to estimate? 20 Find a Baseline!
  21. 21. Planning Poker Game 21
  22. 22. 22 Succeeding with SCRUM at be2
  23. 23. 23 Creating an Effective Product Vision
  24. 24. 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
  25. 25. Roadmap Planning Sessions 25
  26. 26. Building Quality In 26
  27. 27. 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
  28. 28. INVESTing into good User Stories 28 • Immediately actionable • Negotiable • Valuable • Estimable • Sized to fit in • Testable
  29. 29. 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
  30. 30. 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...
  31. 31. How to make SCRUM work? 31 So what do we need to get SCRUM going well? … 5 things!
  32. 32. 32 TRANSPARENCY
  33. 33. 33 FOCUS
  34. 34. 34 TRUST
  35. 35. 35 COMMITMENT
  36. 36. 36 COURAGE
  37. 37. Some guys that do SCRUM 37
  38. 38. 38 In order to succeed, your desire for success should be greater than your fear of failure. Bill Cosby
  39. 39. 39 Q&A
  40. 40. 40 Thanks for your attention!