the sprints Lemİ Orhan ERGİN Principal Software Engineer @ Sony @lemiorhan Review EFFICIENTLY how to agilistanbul.com

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

The meaning in agile how it should be held recommendations

So let’s check out why we prefer agile development Sotware is the product we aim to develop. for building our product

? Agile = ıncremental + Iterative Agile development is a group of methods based on incremental and iterative development

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 http://availagility.co.uk/2009/12/22/fidelity-the-lost-dimension-of-the-iron-triangle/

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 http://availagility.co.uk/2009/12/22/fidelity-the-lost-dimension-of-the-iron-triangle/

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 http://availagility.co.uk/2009/12/22/fidelity-the-lost-dimension-of-the-iron-triangle/

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 http://availagility.co.uk/2009/12/22/fidelity-the-lost-dimension-of-the-iron-triangle/

design, implementation and infrastructure evolving The aim of agile development is

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

Show the customers and stakeholders the work they have accomplished over the sprint reasons to conduct Inspect the sprint and adapt the product backlog for the next sprint Gather feedback and foster collaboration

The meaning in agile how it should be held recommendations

At the end of each iteration timings Timeboxed 4 hours for a 1 month iteration

No internet through cellphones or laptops meeting guidelines Mails should only be checked on breaks Only urgent calls are allowed common rules

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 guidelines agenda, Breaks & Rules

Product Owner facilitates the meeting, but it not uncommon to have team members run the meeting The whole team and stakeholders attend PEOPLE the attendees The format and the rules should be explained to the ones who has no experience

Product Owner is the one who says ship it and gives "done!" decision Product Owner is not a customer representative PEOPLE Product Owner Product Owner identifies done and not-done items, discusses backlog and deadlines

No slides are allowed. Working software is reviewed The team should be prepared for the review in advance PEOPLE Development team All team members should participate in the review

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 Agreements that the review will be based on Let’s jump to these topics for few minutes

acceptance criteria

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 criteria what is it? The criteria defined by Product Owner to assess completed stories. It is also be called “Conditions of Satisfaction”

Acceptance criteria Features 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

Acceptance criteria Example 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:

definition of done

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 done what is it? DoD is a checklist of valuable activities required to produce software

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?

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?

? 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

definition of done What 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

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

must-haves section 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

must-haves section 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)

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

section of the review meeting should-haves Success Rates of Continuous Integration Builds Support Cases Available Bugs Test/Code Coverage Release Notes Change Log

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

The meaning in agile how it should be held recommendations

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

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

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

Pre-review with the Product Owner

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.

Problem Too much technical discussions recommendation DoD should cover quality standards Technical details should be clarified in the sprint before the meeting

Problem Some people are talking, the others are sleeping recommendation Everyone should participate in the meeting, no excuse

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

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..

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

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

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

Problem Stakeholders are bored recommendation Focus on the demo and avoid going into too much detail Separate the meeting into two sections

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

Photos used in the slidES http://www.flickr.com/photos/therahim/5587920310 http://www.flickr.com/photos/mesfoto/4245156422 http://www.flickr.com/photos/keysring/3493912575 http://www.flickr.com/photos/bealluc/158962685 http://www.flickr.com/photos/unclefuz/4506302304 http://i48.tinypic.com/2saghhs.jpg References Definition of Done: http://www.scrumalliance.org/community/articles/2008/september/what-is-definition-of-done-(dod) http://www.agilistanbul.com/2012/12/definition-of-done-nin-gucu.html Big Bang, Iterative, Incremental, Agile: http://availagility.co.uk/2009/12/22/fidelity-the-lost-dimension-of-the-iron-triangle/ Acceptance Criteria: http://wiki.servicenow.com/index.php?title=Well-Written_Scrum_Stories#Story_Acceptance_Criteria

Lemİ orhan ergİn lemiorhan@agilistanbul.com @lemiorhan @lemiorhan agilistanbul.com @lemiorhan LINKEDIN TWITTER SLIDESHARE BLOG Principal Software Engineer @ Sony Founder & Author @ agilistanbul.com flyingtomoon.com