How To Review The Sprints Efficiently


Published on

I am covering the details of review meetings in agile culture and practical tips to make these meetings more effective and productive.

Published in: Technology, Business

How To Review The Sprints Efficiently

  1. the sprints Lemİ Orhan ERGİN Principal Software Engineer @ Sony @lemiorhan Review EFFICIENTLY how to
  2. Lemİ Orhan Ergİn Principal Software Engineer in Sony has worked in Tüsside, BYM, GittiGidiyor/eBay and Sony as lead developer, team leader, technical coordinator and scrum master got CSM certificate from Jim Coplien year as Scrum Master sprints in 4 years as team member and scrum master experienced in agile transformation and building agile culture in teams & organizations 2001 2013 2009 1 56 agile CSM, PSM1
  3. The meaning in agile how it should be held recommendations
  4. So let’s check out why we prefer agile development Sotware is the product we aim to develop. for building our product
  5. ?Agile = ıncremental + Iterative Agile development is a group of methods based on incremental and iterative development
  6. A Big Bang approach is neither iterative or incremental. Architectural components are built to full fidelity, for the full scope, and are fully integrated once at the end. bing bang Data and images are originally from “Fidelity – The Lost Dimension of the Iron Triangle” article by Karl Scotland
  7. The purely incremental approach builds each feature, across all components, to full fidelity, one by one. Incremental Data and images are originally from “Fidelity – The Lost Dimension of the Iron Triangle” article by Karl Scotland
  8. The purely iterative approach builds all the features, across all components, to the lowest fidelity, and then increases the fidelity to the highest level. ıterative Data and images are originally from “Fidelity – The Lost Dimension of the Iron Triangle” article by Karl Scotland
  9. An Agile approach combines the incremental and iterative approach by building each feature, one by one, at a low fidelity, and then both gradually adding features andincreasing their fidelity until the right combination is achieved. Full fidelity is not always necessary. agile Data and images are originally from “Fidelity – The Lost Dimension of the Iron Triangle” article by Karl Scotland
  10. design, implementation and infrastructure evolving The aim of agile development is
  11. Review Meetings are organized to review the status of evolution of the product with stakeholders and customers and direct the focus on business value controlled evolution
  12. Show the customers and stakeholders the work they have accomplished over the sprint reasonstoconduct Inspect the sprint and adapt the product backlog for the next sprint Gather feedback and foster collaboration
  13. The meaning in agile how it should be held recommendations
  14. At the end of each iteration timings Timeboxed4 hours for a 1 month iteration
  15. No internet through cellphones or laptops meeting guidelines Mails should only be checked on breaks Only urgent calls are allowed common rules
  16. Timing/agenda should be written on white board Agenda, timings and meeting rules should be mentioned at the beginning of the meeting Strictly give breaks and obey the timings meeting guidelinesagenda, Breaks & Rules
  17. Product Owner facilitates the meeting, but it not uncommon to have team members run the meeting The whole team and stakeholders attend PEOPLEthe attendees The format and the rules should be explained to the ones who has no experience
  18. Product Owner is the one who says ship it and gives "done!" decision Product Owner is not a customer representative PEOPLEProduct Owner Product Owner identifies done and not-done items, discusses backlog and deadlines
  19. No slides are allowed. Working software is reviewed The team should be prepared for the review in advance PEOPLEDevelopment team All team members should participate in the review
  20. Definition of Done should be defined and agreed by the team in advance Acceptance criteria should be defined for each story in the planning meeting Agreementsthat the review will be based on Let’s jump to these topics for few minutes
  21. acceptance criteria
  22. Acceptance criteria define the boundaries of a user story, and are used to confirm when the software is working as intended, which means the story is completed Acceptance criteriawhat is it? The criteria defined by Product Owner to assess completed stories. It is also be called “Conditions of Satisfaction”
  23. Acceptance criteriaFeatures of a good acceptance criteria Usability Funcitonality error handling Performance Stress tests Include measures of usability Identify specific user tasks, business processes or functions that must be in place at the end of the project Enumerate error cases and how each should be handled Test system performance from the perspective of an individual user Acceptable threasholds should be defined for stress testing
  24. Acceptance criteriaExample of a Good acceptance criteria As a customer, I want to order and pay for the book via a secure web-based form, so that my credit card information is safe. Description: ✴All mandatory fields must be completed before a customer can submit a form. ✴Information from the form is stored in the customer orders database. ✴Payment can be made via Amex, Master Card, or Visa credit card. ✴The system shall accurately calculate and apply sales tax. ✴The system shall accurately calculate and apply shipping charges. ✴The customer shall be able to verify the accuracy of the order. ✴An acknowledgment email is sent to the customer submitting the form. ✴Protection against spam is working. ✴The code should be deployed and running in Staging environment acceptance criteria:
  25. definition of done
  26. Focuses of value added steps Items should add verifiable/demonstrable value to the product Explains in what conditions a PBI is described as "done" It is used for assessing the work when it is completed It guides the team in knowing how many PBIs can be selected definition of donewhat is it? DoD is a checklist of valuable activities required to produce software
  27. The team should decide the items in the DoD list DoD is not static, it changes over time DoD should be reviewed in retrospectives definition of done DoD is the primary reporting mechanism for team members How Related with The team?
  28. DoD for a task DoD for a feature/story DoD for a iteration/sprint DoD for a release definition of done DoD is informed by the reality What kind of DOD we can have?
  29. ? Code is readable, it documents itself JavaDoc and inline comments are entered Code is refactored Code obeys clean code principles Code obeys naming conventions and indentation rules definition of done Not a good idea, since DOD items should be verifiable/demonstrable Clean Code Principles as DOD? Clean Code Principles are already a must
  30. definition of doneWhat can be the Dod entries? DOD for Tasks DOD for stories DOD for Sprints DOD for releases Unit tests are written CI default builds are green Integration/acceptance tests are written Design/analysis documents are written No critical bugs Code is reviewed by peers Demo scenarios are created All CI builds are green No major & critical bugs Code coverage calculated SIT is done Performance/load tests are completed Release notes are prepared Cutover plan is prepared UAT is done As the team mature, the DoD could expand for higher quality Fits to acceptance criteria
  31. For reviewing the points having business value with customers and stakeholders For reviewing the points directly related with the technical improvements, refactoring, quality metrics with the team must-haves should-haves two sections split the review into
  32. must-havessection of the review meeting Focuses on stories having business value Audience does not expect to have too much technical detail Acceptance criteria should pass The product should be potentially shippable
  33. must-havessection of the review meeting Technical Dept (If it’s worth mentioning to stakeholders) Features/Stories with Demo (The ones the team commited to delivering) Major/Critical bugs (Could change according to DoD) Key Decisions (Could be technical, market driven, requirements and made by anyone else)
  34. section of the review meeting No need to have stakeholders in the meeting Technical details could be reviewed Focuses quality of implementation and support should-haves
  35. section of the review meeting should-haves Success Rates of Continuous Integration Builds Support Cases Available Bugs Test/Code Coverage Release Notes Change Log
  36. All attendees collaborate on what to do next Use retrospective to improve the efficiency of review meetings All missing points should be noted to add to next iterations as new tasks or stories Finalizing the meeting
  37. The meaning in agile how it should be held recommendations
  38. The development teams has to be prepared in advance to the meeting. At most 1 hour preparation per sprint should be enough for the team. Problem Demo/Review is too slow. Development team spends too much time for preparing the demo. recommendation
  39. Doing a simulation of the review for complex stories before the meeting will make the team be sure about the software. Problem Software is not working in the demo even though it was working before the meeting recommendation
  40. Focus on reviewing what has done and do not go off the road Pre-reviews by product owner should be done by the team Team should be prepared for the review Allowing too many external audience might cause to exceed the timebox Problem Meeting exceeds timebox recommendation Let’s jump to pre-review topic for few minutes
  41. Pre-reviewwith the Product Owner
  42. Whenever a story is completed (or almost completed), ask PO to spend few minutes to review all the details Pre-review with PO It is safer to review with PO before the review meeting to notice missing points and misunderstandings in advance What is it about? That increases success rates of developments, and as a side effect, the efficiency of review meetings is improved.
  43. Problem Too much technical discussions recommendation DoD should cover quality standards Technical details should be clarified in the sprint before the meeting
  44. Problem Some people are talking, the others are sleeping recommendation Everyone should participate in the meeting, no excuse
  45. Problem People are not following the meeting, just surfing and chatting recommendation Internet should be closed in cellphones and laptops Mails should be checked on breaks Only urgent calls are allowed These rules should be mentioned in the beginning of the meeting
  46. Problem The team is cheating on what is done and not done recommendation Trust is a must Everything should be transparent, including the failures No blaming, no finger-pointing..
  47. Problem Chaos in the meeting recommendation Show agenda to the team and the progress of the meeting Remind the rules of review meetings to the team
  48. Problem Too much negotiation with the Product Owner about accepting the stories recommendation Acceptance criteria should be defined in advance DoD should be checked by team in advance All parties should be positive and objective
  49. Problem The team gives status reports to Product Owner recommendation It is not a status report of individual team members It is not a "what I did in the last sprint" discussion It is not a status meeting
  50. Problem Stakeholders are bored recommendation Focus on the demo and avoid going into too much detail Separate the meeting into two sections
  51. Problem Product Owner changed its mind about the predefined acceptance criteria during the review recommendation Too late for any change, stories are reviewed by the agreed acceptance criteria Product Owner adds new items to the next sprint if required
  52. Photos used in the slidES References Definition of Done: Big Bang, Iterative, Incremental, Agile: Acceptance Criteria:
  53. Lemİ orhan ergİn @lemiorhan @lemiorhan @lemiorhan LINKEDINTWITTERSLIDESHAREBLOG Principal Software Engineer @ Sony Founder & Author @