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

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

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

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. 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. 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. 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
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. Lemİ orhan ergİn
lemiorhan@agilistanbul.com
@lemiorhan
@lemiorhan
agilistanbul.com
@lemiorhan
LINKEDINTWITTERSLIDESHAREBLOG
Principal Software Engineer @ Sony
Founder & Author @ agilistanbul.com
flyingtomoon.com