0
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 develo...
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 ...
The purely incremental approach builds each
feature, across all components, to full fidelity,
one by one.
Incremental
Data ...
The purely iterative approach builds all the
features, across all components, to the lowest
fidelity, and then increases th...
An Agile approach combines the incremental
and iterative approach by building each feature,
one by one, at a low fidelity, ...
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 ...
Show the customers and stakeholders the work
they have accomplished over the sprint
reasonstoconduct
Inspect the sprint an...
The meaning in agile
how it should be held
recommendations
At the end of
each iteration
timings
Timeboxed4 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 ...
Timing/agenda should be
written on white board
Agenda, timings and
meeting rules should be
mentioned at the beginning
of t...
Product Owner facilitates the
meeting, but it not uncommon to have
team members run the meeting
The whole team and
stakeho...
Product Owner is the one
who says ship it and
gives "done!" decision
Product Owner is not a
customer representative
PEOPLE...
No slides are allowed.
Working software is reviewed
The team should be prepared
for the review in advance
PEOPLEDevelopmen...
Definition of Done should be
defined and agreed by the
team in advance
Acceptance criteria should be
defined for each story i...
acceptance
criteria
Acceptance criteria define the boundaries of a user story,
and are used to confirm when the software is working as intended,...
Acceptance criteriaFeatures of a good acceptance criteria
Usability Funcitonality error handling Performance Stress tests
...
Acceptance criteriaExample of a Good acceptance criteria
As a customer, I want to order and pay for the book via a secure ...
definition of done
Focuses of value added steps
Items should add verifiable/demonstrable value to the product
Explains in what conditions a PB...
The team should decide the items in the DoD list
DoD is not static, it changes over time
DoD should be reviewed in retrosp...
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 ...
?
Code is readable, it documents itself
JavaDoc and inline comments are entered
Code is refactored
Code obeys clean code p...
definition of doneWhat can be the Dod entries?
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests a...
For reviewing the
points having business
value with customers
and stakeholders
For reviewing the points
directly related w...
must-havessection of the review meeting
Focuses on stories having business value
Audience does not expect to have too much...
must-havessection of the review meeting
Technical Dept
(If it’s worth mentioning to stakeholders)
Features/Stories with De...
section of the review meeting
No need to have stakeholders in the meeting
Technical details could be reviewed
Focuses qual...
section of the review meeting
should-haves
Success Rates of Continuous Integration Builds
Support Cases
Available Bugs
Tes...
All attendees collaborate
on what to do next
Use retrospective to
improve the efficiency of
review meetings
All missing poi...
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...
Doing a simulation of the review for complex stories before
the meeting will make the team be sure about the software.
Pro...
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 s...
Pre-reviewwith 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...
Problem
Too much technical discussions
recommendation
DoD should cover quality standards
Technical details should be clari...
Problem
Some people are talking, the others are sleeping
recommendation
Everyone should participate in the meeting, no exc...
Problem
People are not following the meeting, just surfing and chatting
recommendation
Internet should be closed in cellpho...
Problem
The team is cheating on what is done and not done
recommendation
Trust is a must
Everything should be transparent,...
Problem
Chaos in the meeting
recommendation
Show agenda to the team and the progress of the meeting
Remind the rules of re...
Problem
Too much negotiation with the Product Owner
about accepting the stories
recommendation
Acceptance criteria should ...
Problem
The team gives status reports to Product Owner
recommendation
It is not a status report of individual team members...
Problem
Stakeholders are bored
recommendation
Focus on the demo and avoid going into too much detail
Separate the meeting ...
Problem
Product Owner changed its mind about the predefined
acceptance criteria during the review
recommendation
Too late f...
Photos used in the slidES
http://www.flickr.com/photos/therahim/5587920310
http://www.flickr.com/photos/mesfoto/4245156422
h...
Lemİ orhan ergİn
lemiorhan@agilistanbul.com
@lemiorhan
@lemiorhan
agilistanbul.com
@lemiorhan
LINKEDINTWITTERSLIDESHAREBLO...
Upcoming SlideShare
Loading in...5
×

How To Review The Sprints Efficiently

53,818

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
1 Comment
23 Likes
Statistics
Notes
No Downloads
Views
Total Views
53,818
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
97
Comments
1
Likes
23
Embeds 0
No embeds

No notes for slide

Transcript of "How To Review The Sprints Efficiently"

  1. 1. the sprints Lemİ Orhan ERGİN Principal Software Engineer @ Sony @lemiorhan Review EFFICIENTLY how to agilistanbul.com
  2. 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. 3. The meaning in agile how it should be held recommendations
  4. 4. So let’s check out why we prefer agile development Sotware is the product we aim to develop. for building our product
  5. 5. ?Agile = ıncremental + Iterative Agile development is a group of methods based on incremental and iterative development
  6. 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 http://availagility.co.uk/2009/12/22/fidelity-the-lost-dimension-of-the-iron-triangle/
  7. 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 http://availagility.co.uk/2009/12/22/fidelity-the-lost-dimension-of-the-iron-triangle/
  8. 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 http://availagility.co.uk/2009/12/22/fidelity-the-lost-dimension-of-the-iron-triangle/
  9. 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 http://availagility.co.uk/2009/12/22/fidelity-the-lost-dimension-of-the-iron-triangle/
  10. 10. design, implementation and infrastructure evolving The aim of agile development is
  11. 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. 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. 13. The meaning in agile how it should be held recommendations
  14. 14. At the end of each iteration timings Timeboxed4 hours for a 1 month iteration
  15. 15. No internet through cellphones or laptops meeting guidelines Mails should only be checked on breaks Only urgent calls are allowed common rules
  16. 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. 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. 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. 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. 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. 21. acceptance criteria
  22. 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. 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. 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. 25. definition of done
  26. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 37. The meaning in agile how it should be held recommendations
  38. 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. 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. 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. 41. Pre-reviewwith the Product Owner
  42. 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. 43. Problem Too much technical discussions recommendation DoD should cover quality standards Technical details should be clarified in the sprint before the meeting
  44. 44. Problem Some people are talking, the others are sleeping recommendation Everyone should participate in the meeting, no excuse
  45. 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. 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. 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. 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. 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. 50. Problem Stakeholders are bored recommendation Focus on the demo and avoid going into too much detail Separate the meeting into two sections
  51. 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. 52. 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
  53. 53. Lemİ orhan ergİn lemiorhan@agilistanbul.com @lemiorhan @lemiorhan agilistanbul.com @lemiorhan LINKEDINTWITTERSLIDESHAREBLOG Principal Software Engineer @ Sony Founder & Author @ agilistanbul.com flyingtomoon.com
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×