how to review the sprints efficiently
DESCRIPTION
I am covering the details of review meetings in agile culture and practical tips to make these meetings more effective and productive.TRANSCRIPT
the sprints
Lemİ Orhan ERGİNPrincipal Software Engineer Sony
lemiorhan
ReviewEFFICIENTLY
how to
agilistanbulcom
Lemİ Orhan Ergİn
Principal Software Engineer in Sony
has worked in Tuumlsside BYM GittiGidiyoreBay 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 amp organizations
2001
2013
20091
56
agile
CSM PSM1
The meaning in agilehow it should be heldrecommendations
So letrsquos check out why we prefer
agile developmentSotware 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 ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-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 ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-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 ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-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 ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
design implementation and infrastructureevolving
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
reas
ons t
o con
duct
Inspect the sprint and adapt the product backlog for the next sprint
Gather feedback and foster collaboration
The meaning in agilehow it should be heldrecommendations
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 allowed
common rules
Timingagenda 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 amp Rules
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
Product Owner is the one who says ship it and
gives done decision
Product Owner is not a customer representative
PEOPLEProduct Owner
Product Owner identifiesdone 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
PEOPLEDevelopment 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
Agreementsthat the review will be based on
Letrsquos jump to these topics for few minutes
acceptancecriteria
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 storiesIt is also be called ldquoConditions of Satisfactionrdquo
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
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 formInformation from the form is stored in the customer orders databasePayment can be made via Amex Master Card or Visa credit cardThe system shall accurately calculate and apply sales taxThe system shall accurately calculate and apply shipping chargesThe customer shall be able to verify the accuracy of the orderAn acknowledgment email is sent to the customer submitting the formProtection against spam is workingThe code should be deployed and running in Staging environment
acceptance criteria
definition of done
Focuses of value added steps Items should add verifiabledemonstrable 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
The team should decide the items in the DoD listDoD is not static it changes over time
DoD should be reviewed in retrospectives
definition of doneDoD is the primary reporting mechanism for team members
How Related with The team
DoD for a task DoD for a featurestory
DoD for a iterationsprint DoD for a release
definition of doneDoD is informed by the reality
What kind of DOD we can have
Code is readable it documents itselfJavaDoc and inline comments are entered
Code is refactoredCode obeys clean code principles
Code obeys naming conventions and indentation rules
definition of doneNot a good idea since DOD items should be verifiabledemonstrable
Clean Code Principles as DOD
Clean Code Principles are already a must
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
Lemİ Orhan Ergİn
Principal Software Engineer in Sony
has worked in Tuumlsside BYM GittiGidiyoreBay 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 amp organizations
2001
2013
20091
56
agile
CSM PSM1
The meaning in agilehow it should be heldrecommendations
So letrsquos check out why we prefer
agile developmentSotware 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 ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-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 ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-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 ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-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 ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
design implementation and infrastructureevolving
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
reas
ons t
o con
duct
Inspect the sprint and adapt the product backlog for the next sprint
Gather feedback and foster collaboration
The meaning in agilehow it should be heldrecommendations
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 allowed
common rules
Timingagenda 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 amp Rules
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
Product Owner is the one who says ship it and
gives done decision
Product Owner is not a customer representative
PEOPLEProduct Owner
Product Owner identifiesdone 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
PEOPLEDevelopment 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
Agreementsthat the review will be based on
Letrsquos jump to these topics for few minutes
acceptancecriteria
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 storiesIt is also be called ldquoConditions of Satisfactionrdquo
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
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 formInformation from the form is stored in the customer orders databasePayment can be made via Amex Master Card or Visa credit cardThe system shall accurately calculate and apply sales taxThe system shall accurately calculate and apply shipping chargesThe customer shall be able to verify the accuracy of the orderAn acknowledgment email is sent to the customer submitting the formProtection against spam is workingThe code should be deployed and running in Staging environment
acceptance criteria
definition of done
Focuses of value added steps Items should add verifiabledemonstrable 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
The team should decide the items in the DoD listDoD is not static it changes over time
DoD should be reviewed in retrospectives
definition of doneDoD is the primary reporting mechanism for team members
How Related with The team
DoD for a task DoD for a featurestory
DoD for a iterationsprint DoD for a release
definition of doneDoD is informed by the reality
What kind of DOD we can have
Code is readable it documents itselfJavaDoc and inline comments are entered
Code is refactoredCode obeys clean code principles
Code obeys naming conventions and indentation rules
definition of doneNot a good idea since DOD items should be verifiabledemonstrable
Clean Code Principles as DOD
Clean Code Principles are already a must
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
The meaning in agilehow it should be heldrecommendations
So letrsquos check out why we prefer
agile developmentSotware 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 ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-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 ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-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 ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-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 ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
design implementation and infrastructureevolving
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
reas
ons t
o con
duct
Inspect the sprint and adapt the product backlog for the next sprint
Gather feedback and foster collaboration
The meaning in agilehow it should be heldrecommendations
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 allowed
common rules
Timingagenda 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 amp Rules
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
Product Owner is the one who says ship it and
gives done decision
Product Owner is not a customer representative
PEOPLEProduct Owner
Product Owner identifiesdone 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
PEOPLEDevelopment 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
Agreementsthat the review will be based on
Letrsquos jump to these topics for few minutes
acceptancecriteria
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 storiesIt is also be called ldquoConditions of Satisfactionrdquo
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
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 formInformation from the form is stored in the customer orders databasePayment can be made via Amex Master Card or Visa credit cardThe system shall accurately calculate and apply sales taxThe system shall accurately calculate and apply shipping chargesThe customer shall be able to verify the accuracy of the orderAn acknowledgment email is sent to the customer submitting the formProtection against spam is workingThe code should be deployed and running in Staging environment
acceptance criteria
definition of done
Focuses of value added steps Items should add verifiabledemonstrable 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
The team should decide the items in the DoD listDoD is not static it changes over time
DoD should be reviewed in retrospectives
definition of doneDoD is the primary reporting mechanism for team members
How Related with The team
DoD for a task DoD for a featurestory
DoD for a iterationsprint DoD for a release
definition of doneDoD is informed by the reality
What kind of DOD we can have
Code is readable it documents itselfJavaDoc and inline comments are entered
Code is refactoredCode obeys clean code principles
Code obeys naming conventions and indentation rules
definition of doneNot a good idea since DOD items should be verifiabledemonstrable
Clean Code Principles as DOD
Clean Code Principles are already a must
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
So letrsquos check out why we prefer
agile developmentSotware 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 ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-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 ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-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 ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-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 ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
design implementation and infrastructureevolving
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
reas
ons t
o con
duct
Inspect the sprint and adapt the product backlog for the next sprint
Gather feedback and foster collaboration
The meaning in agilehow it should be heldrecommendations
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 allowed
common rules
Timingagenda 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 amp Rules
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
Product Owner is the one who says ship it and
gives done decision
Product Owner is not a customer representative
PEOPLEProduct Owner
Product Owner identifiesdone 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
PEOPLEDevelopment 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
Agreementsthat the review will be based on
Letrsquos jump to these topics for few minutes
acceptancecriteria
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 storiesIt is also be called ldquoConditions of Satisfactionrdquo
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
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 formInformation from the form is stored in the customer orders databasePayment can be made via Amex Master Card or Visa credit cardThe system shall accurately calculate and apply sales taxThe system shall accurately calculate and apply shipping chargesThe customer shall be able to verify the accuracy of the orderAn acknowledgment email is sent to the customer submitting the formProtection against spam is workingThe code should be deployed and running in Staging environment
acceptance criteria
definition of done
Focuses of value added steps Items should add verifiabledemonstrable 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
The team should decide the items in the DoD listDoD is not static it changes over time
DoD should be reviewed in retrospectives
definition of doneDoD is the primary reporting mechanism for team members
How Related with The team
DoD for a task DoD for a featurestory
DoD for a iterationsprint DoD for a release
definition of doneDoD is informed by the reality
What kind of DOD we can have
Code is readable it documents itselfJavaDoc and inline comments are entered
Code is refactoredCode obeys clean code principles
Code obeys naming conventions and indentation rules
definition of doneNot a good idea since DOD items should be verifiabledemonstrable
Clean Code Principles as DOD
Clean Code Principles are already a must
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
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 ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-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 ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-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 ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-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 ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
design implementation and infrastructureevolving
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
reas
ons t
o con
duct
Inspect the sprint and adapt the product backlog for the next sprint
Gather feedback and foster collaboration
The meaning in agilehow it should be heldrecommendations
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 allowed
common rules
Timingagenda 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 amp Rules
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
Product Owner is the one who says ship it and
gives done decision
Product Owner is not a customer representative
PEOPLEProduct Owner
Product Owner identifiesdone 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
PEOPLEDevelopment 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
Agreementsthat the review will be based on
Letrsquos jump to these topics for few minutes
acceptancecriteria
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 storiesIt is also be called ldquoConditions of Satisfactionrdquo
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
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 formInformation from the form is stored in the customer orders databasePayment can be made via Amex Master Card or Visa credit cardThe system shall accurately calculate and apply sales taxThe system shall accurately calculate and apply shipping chargesThe customer shall be able to verify the accuracy of the orderAn acknowledgment email is sent to the customer submitting the formProtection against spam is workingThe code should be deployed and running in Staging environment
acceptance criteria
definition of done
Focuses of value added steps Items should add verifiabledemonstrable 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
The team should decide the items in the DoD listDoD is not static it changes over time
DoD should be reviewed in retrospectives
definition of doneDoD is the primary reporting mechanism for team members
How Related with The team
DoD for a task DoD for a featurestory
DoD for a iterationsprint DoD for a release
definition of doneDoD is informed by the reality
What kind of DOD we can have
Code is readable it documents itselfJavaDoc and inline comments are entered
Code is refactoredCode obeys clean code principles
Code obeys naming conventions and indentation rules
definition of doneNot a good idea since DOD items should be verifiabledemonstrable
Clean Code Principles as DOD
Clean Code Principles are already a must
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
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 ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-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 ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-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 ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-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 ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
design implementation and infrastructureevolving
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
reas
ons t
o con
duct
Inspect the sprint and adapt the product backlog for the next sprint
Gather feedback and foster collaboration
The meaning in agilehow it should be heldrecommendations
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 allowed
common rules
Timingagenda 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 amp Rules
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
Product Owner is the one who says ship it and
gives done decision
Product Owner is not a customer representative
PEOPLEProduct Owner
Product Owner identifiesdone 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
PEOPLEDevelopment 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
Agreementsthat the review will be based on
Letrsquos jump to these topics for few minutes
acceptancecriteria
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 storiesIt is also be called ldquoConditions of Satisfactionrdquo
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
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 formInformation from the form is stored in the customer orders databasePayment can be made via Amex Master Card or Visa credit cardThe system shall accurately calculate and apply sales taxThe system shall accurately calculate and apply shipping chargesThe customer shall be able to verify the accuracy of the orderAn acknowledgment email is sent to the customer submitting the formProtection against spam is workingThe code should be deployed and running in Staging environment
acceptance criteria
definition of done
Focuses of value added steps Items should add verifiabledemonstrable 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
The team should decide the items in the DoD listDoD is not static it changes over time
DoD should be reviewed in retrospectives
definition of doneDoD is the primary reporting mechanism for team members
How Related with The team
DoD for a task DoD for a featurestory
DoD for a iterationsprint DoD for a release
definition of doneDoD is informed by the reality
What kind of DOD we can have
Code is readable it documents itselfJavaDoc and inline comments are entered
Code is refactoredCode obeys clean code principles
Code obeys naming conventions and indentation rules
definition of doneNot a good idea since DOD items should be verifiabledemonstrable
Clean Code Principles as DOD
Clean Code Principles are already a must
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
The purely incremental approach builds each feature across all components to full fidelity
one by one
Incremental
Data and images are originally from ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-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 ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-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 ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
design implementation and infrastructureevolving
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
reas
ons t
o con
duct
Inspect the sprint and adapt the product backlog for the next sprint
Gather feedback and foster collaboration
The meaning in agilehow it should be heldrecommendations
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 allowed
common rules
Timingagenda 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 amp Rules
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
Product Owner is the one who says ship it and
gives done decision
Product Owner is not a customer representative
PEOPLEProduct Owner
Product Owner identifiesdone 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
PEOPLEDevelopment 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
Agreementsthat the review will be based on
Letrsquos jump to these topics for few minutes
acceptancecriteria
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 storiesIt is also be called ldquoConditions of Satisfactionrdquo
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
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 formInformation from the form is stored in the customer orders databasePayment can be made via Amex Master Card or Visa credit cardThe system shall accurately calculate and apply sales taxThe system shall accurately calculate and apply shipping chargesThe customer shall be able to verify the accuracy of the orderAn acknowledgment email is sent to the customer submitting the formProtection against spam is workingThe code should be deployed and running in Staging environment
acceptance criteria
definition of done
Focuses of value added steps Items should add verifiabledemonstrable 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
The team should decide the items in the DoD listDoD is not static it changes over time
DoD should be reviewed in retrospectives
definition of doneDoD is the primary reporting mechanism for team members
How Related with The team
DoD for a task DoD for a featurestory
DoD for a iterationsprint DoD for a release
definition of doneDoD is informed by the reality
What kind of DOD we can have
Code is readable it documents itselfJavaDoc and inline comments are entered
Code is refactoredCode obeys clean code principles
Code obeys naming conventions and indentation rules
definition of doneNot a good idea since DOD items should be verifiabledemonstrable
Clean Code Principles as DOD
Clean Code Principles are already a must
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
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 ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-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 ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
design implementation and infrastructureevolving
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
reas
ons t
o con
duct
Inspect the sprint and adapt the product backlog for the next sprint
Gather feedback and foster collaboration
The meaning in agilehow it should be heldrecommendations
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 allowed
common rules
Timingagenda 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 amp Rules
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
Product Owner is the one who says ship it and
gives done decision
Product Owner is not a customer representative
PEOPLEProduct Owner
Product Owner identifiesdone 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
PEOPLEDevelopment 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
Agreementsthat the review will be based on
Letrsquos jump to these topics for few minutes
acceptancecriteria
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 storiesIt is also be called ldquoConditions of Satisfactionrdquo
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
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 formInformation from the form is stored in the customer orders databasePayment can be made via Amex Master Card or Visa credit cardThe system shall accurately calculate and apply sales taxThe system shall accurately calculate and apply shipping chargesThe customer shall be able to verify the accuracy of the orderAn acknowledgment email is sent to the customer submitting the formProtection against spam is workingThe code should be deployed and running in Staging environment
acceptance criteria
definition of done
Focuses of value added steps Items should add verifiabledemonstrable 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
The team should decide the items in the DoD listDoD is not static it changes over time
DoD should be reviewed in retrospectives
definition of doneDoD is the primary reporting mechanism for team members
How Related with The team
DoD for a task DoD for a featurestory
DoD for a iterationsprint DoD for a release
definition of doneDoD is informed by the reality
What kind of DOD we can have
Code is readable it documents itselfJavaDoc and inline comments are entered
Code is refactoredCode obeys clean code principles
Code obeys naming conventions and indentation rules
definition of doneNot a good idea since DOD items should be verifiabledemonstrable
Clean Code Principles as DOD
Clean Code Principles are already a must
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
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 ldquoFidelity ndash The Lost Dimension of the Iron Trianglerdquo article by Karl Scotlandhttpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
design implementation and infrastructureevolving
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
reas
ons t
o con
duct
Inspect the sprint and adapt the product backlog for the next sprint
Gather feedback and foster collaboration
The meaning in agilehow it should be heldrecommendations
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 allowed
common rules
Timingagenda 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 amp Rules
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
Product Owner is the one who says ship it and
gives done decision
Product Owner is not a customer representative
PEOPLEProduct Owner
Product Owner identifiesdone 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
PEOPLEDevelopment 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
Agreementsthat the review will be based on
Letrsquos jump to these topics for few minutes
acceptancecriteria
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 storiesIt is also be called ldquoConditions of Satisfactionrdquo
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
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 formInformation from the form is stored in the customer orders databasePayment can be made via Amex Master Card or Visa credit cardThe system shall accurately calculate and apply sales taxThe system shall accurately calculate and apply shipping chargesThe customer shall be able to verify the accuracy of the orderAn acknowledgment email is sent to the customer submitting the formProtection against spam is workingThe code should be deployed and running in Staging environment
acceptance criteria
definition of done
Focuses of value added steps Items should add verifiabledemonstrable 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
The team should decide the items in the DoD listDoD is not static it changes over time
DoD should be reviewed in retrospectives
definition of doneDoD is the primary reporting mechanism for team members
How Related with The team
DoD for a task DoD for a featurestory
DoD for a iterationsprint DoD for a release
definition of doneDoD is informed by the reality
What kind of DOD we can have
Code is readable it documents itselfJavaDoc and inline comments are entered
Code is refactoredCode obeys clean code principles
Code obeys naming conventions and indentation rules
definition of doneNot a good idea since DOD items should be verifiabledemonstrable
Clean Code Principles as DOD
Clean Code Principles are already a must
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
design implementation and infrastructureevolving
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
reas
ons t
o con
duct
Inspect the sprint and adapt the product backlog for the next sprint
Gather feedback and foster collaboration
The meaning in agilehow it should be heldrecommendations
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 allowed
common rules
Timingagenda 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 amp Rules
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
Product Owner is the one who says ship it and
gives done decision
Product Owner is not a customer representative
PEOPLEProduct Owner
Product Owner identifiesdone 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
PEOPLEDevelopment 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
Agreementsthat the review will be based on
Letrsquos jump to these topics for few minutes
acceptancecriteria
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 storiesIt is also be called ldquoConditions of Satisfactionrdquo
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
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 formInformation from the form is stored in the customer orders databasePayment can be made via Amex Master Card or Visa credit cardThe system shall accurately calculate and apply sales taxThe system shall accurately calculate and apply shipping chargesThe customer shall be able to verify the accuracy of the orderAn acknowledgment email is sent to the customer submitting the formProtection against spam is workingThe code should be deployed and running in Staging environment
acceptance criteria
definition of done
Focuses of value added steps Items should add verifiabledemonstrable 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
The team should decide the items in the DoD listDoD is not static it changes over time
DoD should be reviewed in retrospectives
definition of doneDoD is the primary reporting mechanism for team members
How Related with The team
DoD for a task DoD for a featurestory
DoD for a iterationsprint DoD for a release
definition of doneDoD is informed by the reality
What kind of DOD we can have
Code is readable it documents itselfJavaDoc and inline comments are entered
Code is refactoredCode obeys clean code principles
Code obeys naming conventions and indentation rules
definition of doneNot a good idea since DOD items should be verifiabledemonstrable
Clean Code Principles as DOD
Clean Code Principles are already a must
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
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
reas
ons t
o con
duct
Inspect the sprint and adapt the product backlog for the next sprint
Gather feedback and foster collaboration
The meaning in agilehow it should be heldrecommendations
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 allowed
common rules
Timingagenda 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 amp Rules
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
Product Owner is the one who says ship it and
gives done decision
Product Owner is not a customer representative
PEOPLEProduct Owner
Product Owner identifiesdone 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
PEOPLEDevelopment 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
Agreementsthat the review will be based on
Letrsquos jump to these topics for few minutes
acceptancecriteria
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 storiesIt is also be called ldquoConditions of Satisfactionrdquo
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
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 formInformation from the form is stored in the customer orders databasePayment can be made via Amex Master Card or Visa credit cardThe system shall accurately calculate and apply sales taxThe system shall accurately calculate and apply shipping chargesThe customer shall be able to verify the accuracy of the orderAn acknowledgment email is sent to the customer submitting the formProtection against spam is workingThe code should be deployed and running in Staging environment
acceptance criteria
definition of done
Focuses of value added steps Items should add verifiabledemonstrable 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
The team should decide the items in the DoD listDoD is not static it changes over time
DoD should be reviewed in retrospectives
definition of doneDoD is the primary reporting mechanism for team members
How Related with The team
DoD for a task DoD for a featurestory
DoD for a iterationsprint DoD for a release
definition of doneDoD is informed by the reality
What kind of DOD we can have
Code is readable it documents itselfJavaDoc and inline comments are entered
Code is refactoredCode obeys clean code principles
Code obeys naming conventions and indentation rules
definition of doneNot a good idea since DOD items should be verifiabledemonstrable
Clean Code Principles as DOD
Clean Code Principles are already a must
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
Show the customers and stakeholders the work they have accomplished over the sprint
reas
ons t
o con
duct
Inspect the sprint and adapt the product backlog for the next sprint
Gather feedback and foster collaboration
The meaning in agilehow it should be heldrecommendations
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 allowed
common rules
Timingagenda 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 amp Rules
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
Product Owner is the one who says ship it and
gives done decision
Product Owner is not a customer representative
PEOPLEProduct Owner
Product Owner identifiesdone 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
PEOPLEDevelopment 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
Agreementsthat the review will be based on
Letrsquos jump to these topics for few minutes
acceptancecriteria
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 storiesIt is also be called ldquoConditions of Satisfactionrdquo
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
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 formInformation from the form is stored in the customer orders databasePayment can be made via Amex Master Card or Visa credit cardThe system shall accurately calculate and apply sales taxThe system shall accurately calculate and apply shipping chargesThe customer shall be able to verify the accuracy of the orderAn acknowledgment email is sent to the customer submitting the formProtection against spam is workingThe code should be deployed and running in Staging environment
acceptance criteria
definition of done
Focuses of value added steps Items should add verifiabledemonstrable 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
The team should decide the items in the DoD listDoD is not static it changes over time
DoD should be reviewed in retrospectives
definition of doneDoD is the primary reporting mechanism for team members
How Related with The team
DoD for a task DoD for a featurestory
DoD for a iterationsprint DoD for a release
definition of doneDoD is informed by the reality
What kind of DOD we can have
Code is readable it documents itselfJavaDoc and inline comments are entered
Code is refactoredCode obeys clean code principles
Code obeys naming conventions and indentation rules
definition of doneNot a good idea since DOD items should be verifiabledemonstrable
Clean Code Principles as DOD
Clean Code Principles are already a must
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
The meaning in agilehow it should be heldrecommendations
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 allowed
common rules
Timingagenda 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 amp Rules
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
Product Owner is the one who says ship it and
gives done decision
Product Owner is not a customer representative
PEOPLEProduct Owner
Product Owner identifiesdone 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
PEOPLEDevelopment 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
Agreementsthat the review will be based on
Letrsquos jump to these topics for few minutes
acceptancecriteria
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 storiesIt is also be called ldquoConditions of Satisfactionrdquo
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
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 formInformation from the form is stored in the customer orders databasePayment can be made via Amex Master Card or Visa credit cardThe system shall accurately calculate and apply sales taxThe system shall accurately calculate and apply shipping chargesThe customer shall be able to verify the accuracy of the orderAn acknowledgment email is sent to the customer submitting the formProtection against spam is workingThe code should be deployed and running in Staging environment
acceptance criteria
definition of done
Focuses of value added steps Items should add verifiabledemonstrable 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
The team should decide the items in the DoD listDoD is not static it changes over time
DoD should be reviewed in retrospectives
definition of doneDoD is the primary reporting mechanism for team members
How Related with The team
DoD for a task DoD for a featurestory
DoD for a iterationsprint DoD for a release
definition of doneDoD is informed by the reality
What kind of DOD we can have
Code is readable it documents itselfJavaDoc and inline comments are entered
Code is refactoredCode obeys clean code principles
Code obeys naming conventions and indentation rules
definition of doneNot a good idea since DOD items should be verifiabledemonstrable
Clean Code Principles as DOD
Clean Code Principles are already a must
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
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 allowed
common rules
Timingagenda 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 amp Rules
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
Product Owner is the one who says ship it and
gives done decision
Product Owner is not a customer representative
PEOPLEProduct Owner
Product Owner identifiesdone 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
PEOPLEDevelopment 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
Agreementsthat the review will be based on
Letrsquos jump to these topics for few minutes
acceptancecriteria
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 storiesIt is also be called ldquoConditions of Satisfactionrdquo
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
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 formInformation from the form is stored in the customer orders databasePayment can be made via Amex Master Card or Visa credit cardThe system shall accurately calculate and apply sales taxThe system shall accurately calculate and apply shipping chargesThe customer shall be able to verify the accuracy of the orderAn acknowledgment email is sent to the customer submitting the formProtection against spam is workingThe code should be deployed and running in Staging environment
acceptance criteria
definition of done
Focuses of value added steps Items should add verifiabledemonstrable 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
The team should decide the items in the DoD listDoD is not static it changes over time
DoD should be reviewed in retrospectives
definition of doneDoD is the primary reporting mechanism for team members
How Related with The team
DoD for a task DoD for a featurestory
DoD for a iterationsprint DoD for a release
definition of doneDoD is informed by the reality
What kind of DOD we can have
Code is readable it documents itselfJavaDoc and inline comments are entered
Code is refactoredCode obeys clean code principles
Code obeys naming conventions and indentation rules
definition of doneNot a good idea since DOD items should be verifiabledemonstrable
Clean Code Principles as DOD
Clean Code Principles are already a must
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
No internet through cellphones or laptops
meeting guidelines
Mails should only be checked on breaks
Only urgent calls are allowed
common rules
Timingagenda 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 amp Rules
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
Product Owner is the one who says ship it and
gives done decision
Product Owner is not a customer representative
PEOPLEProduct Owner
Product Owner identifiesdone 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
PEOPLEDevelopment 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
Agreementsthat the review will be based on
Letrsquos jump to these topics for few minutes
acceptancecriteria
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 storiesIt is also be called ldquoConditions of Satisfactionrdquo
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
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 formInformation from the form is stored in the customer orders databasePayment can be made via Amex Master Card or Visa credit cardThe system shall accurately calculate and apply sales taxThe system shall accurately calculate and apply shipping chargesThe customer shall be able to verify the accuracy of the orderAn acknowledgment email is sent to the customer submitting the formProtection against spam is workingThe code should be deployed and running in Staging environment
acceptance criteria
definition of done
Focuses of value added steps Items should add verifiabledemonstrable 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
The team should decide the items in the DoD listDoD is not static it changes over time
DoD should be reviewed in retrospectives
definition of doneDoD is the primary reporting mechanism for team members
How Related with The team
DoD for a task DoD for a featurestory
DoD for a iterationsprint DoD for a release
definition of doneDoD is informed by the reality
What kind of DOD we can have
Code is readable it documents itselfJavaDoc and inline comments are entered
Code is refactoredCode obeys clean code principles
Code obeys naming conventions and indentation rules
definition of doneNot a good idea since DOD items should be verifiabledemonstrable
Clean Code Principles as DOD
Clean Code Principles are already a must
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
Timingagenda 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 amp Rules
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
Product Owner is the one who says ship it and
gives done decision
Product Owner is not a customer representative
PEOPLEProduct Owner
Product Owner identifiesdone 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
PEOPLEDevelopment 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
Agreementsthat the review will be based on
Letrsquos jump to these topics for few minutes
acceptancecriteria
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 storiesIt is also be called ldquoConditions of Satisfactionrdquo
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
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 formInformation from the form is stored in the customer orders databasePayment can be made via Amex Master Card or Visa credit cardThe system shall accurately calculate and apply sales taxThe system shall accurately calculate and apply shipping chargesThe customer shall be able to verify the accuracy of the orderAn acknowledgment email is sent to the customer submitting the formProtection against spam is workingThe code should be deployed and running in Staging environment
acceptance criteria
definition of done
Focuses of value added steps Items should add verifiabledemonstrable 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
The team should decide the items in the DoD listDoD is not static it changes over time
DoD should be reviewed in retrospectives
definition of doneDoD is the primary reporting mechanism for team members
How Related with The team
DoD for a task DoD for a featurestory
DoD for a iterationsprint DoD for a release
definition of doneDoD is informed by the reality
What kind of DOD we can have
Code is readable it documents itselfJavaDoc and inline comments are entered
Code is refactoredCode obeys clean code principles
Code obeys naming conventions and indentation rules
definition of doneNot a good idea since DOD items should be verifiabledemonstrable
Clean Code Principles as DOD
Clean Code Principles are already a must
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
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
Product Owner is the one who says ship it and
gives done decision
Product Owner is not a customer representative
PEOPLEProduct Owner
Product Owner identifiesdone 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
PEOPLEDevelopment 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
Agreementsthat the review will be based on
Letrsquos jump to these topics for few minutes
acceptancecriteria
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 storiesIt is also be called ldquoConditions of Satisfactionrdquo
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
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 formInformation from the form is stored in the customer orders databasePayment can be made via Amex Master Card or Visa credit cardThe system shall accurately calculate and apply sales taxThe system shall accurately calculate and apply shipping chargesThe customer shall be able to verify the accuracy of the orderAn acknowledgment email is sent to the customer submitting the formProtection against spam is workingThe code should be deployed and running in Staging environment
acceptance criteria
definition of done
Focuses of value added steps Items should add verifiabledemonstrable 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
The team should decide the items in the DoD listDoD is not static it changes over time
DoD should be reviewed in retrospectives
definition of doneDoD is the primary reporting mechanism for team members
How Related with The team
DoD for a task DoD for a featurestory
DoD for a iterationsprint DoD for a release
definition of doneDoD is informed by the reality
What kind of DOD we can have
Code is readable it documents itselfJavaDoc and inline comments are entered
Code is refactoredCode obeys clean code principles
Code obeys naming conventions and indentation rules
definition of doneNot a good idea since DOD items should be verifiabledemonstrable
Clean Code Principles as DOD
Clean Code Principles are already a must
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
Product Owner is the one who says ship it and
gives done decision
Product Owner is not a customer representative
PEOPLEProduct Owner
Product Owner identifiesdone 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
PEOPLEDevelopment 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
Agreementsthat the review will be based on
Letrsquos jump to these topics for few minutes
acceptancecriteria
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 storiesIt is also be called ldquoConditions of Satisfactionrdquo
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
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 formInformation from the form is stored in the customer orders databasePayment can be made via Amex Master Card or Visa credit cardThe system shall accurately calculate and apply sales taxThe system shall accurately calculate and apply shipping chargesThe customer shall be able to verify the accuracy of the orderAn acknowledgment email is sent to the customer submitting the formProtection against spam is workingThe code should be deployed and running in Staging environment
acceptance criteria
definition of done
Focuses of value added steps Items should add verifiabledemonstrable 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
The team should decide the items in the DoD listDoD is not static it changes over time
DoD should be reviewed in retrospectives
definition of doneDoD is the primary reporting mechanism for team members
How Related with The team
DoD for a task DoD for a featurestory
DoD for a iterationsprint DoD for a release
definition of doneDoD is informed by the reality
What kind of DOD we can have
Code is readable it documents itselfJavaDoc and inline comments are entered
Code is refactoredCode obeys clean code principles
Code obeys naming conventions and indentation rules
definition of doneNot a good idea since DOD items should be verifiabledemonstrable
Clean Code Principles as DOD
Clean Code Principles are already a must
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
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
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
Letrsquos jump to these topics for few minutes
acceptancecriteria
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 storiesIt is also be called ldquoConditions of Satisfactionrdquo
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
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 formInformation from the form is stored in the customer orders databasePayment can be made via Amex Master Card or Visa credit cardThe system shall accurately calculate and apply sales taxThe system shall accurately calculate and apply shipping chargesThe customer shall be able to verify the accuracy of the orderAn acknowledgment email is sent to the customer submitting the formProtection against spam is workingThe code should be deployed and running in Staging environment
acceptance criteria
definition of done
Focuses of value added steps Items should add verifiabledemonstrable 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
The team should decide the items in the DoD listDoD is not static it changes over time
DoD should be reviewed in retrospectives
definition of doneDoD is the primary reporting mechanism for team members
How Related with The team
DoD for a task DoD for a featurestory
DoD for a iterationsprint DoD for a release
definition of doneDoD is informed by the reality
What kind of DOD we can have
Code is readable it documents itselfJavaDoc and inline comments are entered
Code is refactoredCode obeys clean code principles
Code obeys naming conventions and indentation rules
definition of doneNot a good idea since DOD items should be verifiabledemonstrable
Clean Code Principles as DOD
Clean Code Principles are already a must
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
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
Letrsquos jump to these topics for few minutes
acceptancecriteria
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 storiesIt is also be called ldquoConditions of Satisfactionrdquo
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
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 formInformation from the form is stored in the customer orders databasePayment can be made via Amex Master Card or Visa credit cardThe system shall accurately calculate and apply sales taxThe system shall accurately calculate and apply shipping chargesThe customer shall be able to verify the accuracy of the orderAn acknowledgment email is sent to the customer submitting the formProtection against spam is workingThe code should be deployed and running in Staging environment
acceptance criteria
definition of done
Focuses of value added steps Items should add verifiabledemonstrable 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
The team should decide the items in the DoD listDoD is not static it changes over time
DoD should be reviewed in retrospectives
definition of doneDoD is the primary reporting mechanism for team members
How Related with The team
DoD for a task DoD for a featurestory
DoD for a iterationsprint DoD for a release
definition of doneDoD is informed by the reality
What kind of DOD we can have
Code is readable it documents itselfJavaDoc and inline comments are entered
Code is refactoredCode obeys clean code principles
Code obeys naming conventions and indentation rules
definition of doneNot a good idea since DOD items should be verifiabledemonstrable
Clean Code Principles as DOD
Clean Code Principles are already a must
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
acceptancecriteria
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 storiesIt is also be called ldquoConditions of Satisfactionrdquo
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
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 formInformation from the form is stored in the customer orders databasePayment can be made via Amex Master Card or Visa credit cardThe system shall accurately calculate and apply sales taxThe system shall accurately calculate and apply shipping chargesThe customer shall be able to verify the accuracy of the orderAn acknowledgment email is sent to the customer submitting the formProtection against spam is workingThe code should be deployed and running in Staging environment
acceptance criteria
definition of done
Focuses of value added steps Items should add verifiabledemonstrable 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
The team should decide the items in the DoD listDoD is not static it changes over time
DoD should be reviewed in retrospectives
definition of doneDoD is the primary reporting mechanism for team members
How Related with The team
DoD for a task DoD for a featurestory
DoD for a iterationsprint DoD for a release
definition of doneDoD is informed by the reality
What kind of DOD we can have
Code is readable it documents itselfJavaDoc and inline comments are entered
Code is refactoredCode obeys clean code principles
Code obeys naming conventions and indentation rules
definition of doneNot a good idea since DOD items should be verifiabledemonstrable
Clean Code Principles as DOD
Clean Code Principles are already a must
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
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 storiesIt is also be called ldquoConditions of Satisfactionrdquo
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
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 formInformation from the form is stored in the customer orders databasePayment can be made via Amex Master Card or Visa credit cardThe system shall accurately calculate and apply sales taxThe system shall accurately calculate and apply shipping chargesThe customer shall be able to verify the accuracy of the orderAn acknowledgment email is sent to the customer submitting the formProtection against spam is workingThe code should be deployed and running in Staging environment
acceptance criteria
definition of done
Focuses of value added steps Items should add verifiabledemonstrable 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
The team should decide the items in the DoD listDoD is not static it changes over time
DoD should be reviewed in retrospectives
definition of doneDoD is the primary reporting mechanism for team members
How Related with The team
DoD for a task DoD for a featurestory
DoD for a iterationsprint DoD for a release
definition of doneDoD is informed by the reality
What kind of DOD we can have
Code is readable it documents itselfJavaDoc and inline comments are entered
Code is refactoredCode obeys clean code principles
Code obeys naming conventions and indentation rules
definition of doneNot a good idea since DOD items should be verifiabledemonstrable
Clean Code Principles as DOD
Clean Code Principles are already a must
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
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
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 formInformation from the form is stored in the customer orders databasePayment can be made via Amex Master Card or Visa credit cardThe system shall accurately calculate and apply sales taxThe system shall accurately calculate and apply shipping chargesThe customer shall be able to verify the accuracy of the orderAn acknowledgment email is sent to the customer submitting the formProtection against spam is workingThe code should be deployed and running in Staging environment
acceptance criteria
definition of done
Focuses of value added steps Items should add verifiabledemonstrable 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
The team should decide the items in the DoD listDoD is not static it changes over time
DoD should be reviewed in retrospectives
definition of doneDoD is the primary reporting mechanism for team members
How Related with The team
DoD for a task DoD for a featurestory
DoD for a iterationsprint DoD for a release
definition of doneDoD is informed by the reality
What kind of DOD we can have
Code is readable it documents itselfJavaDoc and inline comments are entered
Code is refactoredCode obeys clean code principles
Code obeys naming conventions and indentation rules
definition of doneNot a good idea since DOD items should be verifiabledemonstrable
Clean Code Principles as DOD
Clean Code Principles are already a must
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
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 formInformation from the form is stored in the customer orders databasePayment can be made via Amex Master Card or Visa credit cardThe system shall accurately calculate and apply sales taxThe system shall accurately calculate and apply shipping chargesThe customer shall be able to verify the accuracy of the orderAn acknowledgment email is sent to the customer submitting the formProtection against spam is workingThe code should be deployed and running in Staging environment
acceptance criteria
definition of done
Focuses of value added steps Items should add verifiabledemonstrable 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
The team should decide the items in the DoD listDoD is not static it changes over time
DoD should be reviewed in retrospectives
definition of doneDoD is the primary reporting mechanism for team members
How Related with The team
DoD for a task DoD for a featurestory
DoD for a iterationsprint DoD for a release
definition of doneDoD is informed by the reality
What kind of DOD we can have
Code is readable it documents itselfJavaDoc and inline comments are entered
Code is refactoredCode obeys clean code principles
Code obeys naming conventions and indentation rules
definition of doneNot a good idea since DOD items should be verifiabledemonstrable
Clean Code Principles as DOD
Clean Code Principles are already a must
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
definition of done
Focuses of value added steps Items should add verifiabledemonstrable 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
The team should decide the items in the DoD listDoD is not static it changes over time
DoD should be reviewed in retrospectives
definition of doneDoD is the primary reporting mechanism for team members
How Related with The team
DoD for a task DoD for a featurestory
DoD for a iterationsprint DoD for a release
definition of doneDoD is informed by the reality
What kind of DOD we can have
Code is readable it documents itselfJavaDoc and inline comments are entered
Code is refactoredCode obeys clean code principles
Code obeys naming conventions and indentation rules
definition of doneNot a good idea since DOD items should be verifiabledemonstrable
Clean Code Principles as DOD
Clean Code Principles are already a must
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
Focuses of value added steps Items should add verifiabledemonstrable 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
The team should decide the items in the DoD listDoD is not static it changes over time
DoD should be reviewed in retrospectives
definition of doneDoD is the primary reporting mechanism for team members
How Related with The team
DoD for a task DoD for a featurestory
DoD for a iterationsprint DoD for a release
definition of doneDoD is informed by the reality
What kind of DOD we can have
Code is readable it documents itselfJavaDoc and inline comments are entered
Code is refactoredCode obeys clean code principles
Code obeys naming conventions and indentation rules
definition of doneNot a good idea since DOD items should be verifiabledemonstrable
Clean Code Principles as DOD
Clean Code Principles are already a must
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
The team should decide the items in the DoD listDoD is not static it changes over time
DoD should be reviewed in retrospectives
definition of doneDoD is the primary reporting mechanism for team members
How Related with The team
DoD for a task DoD for a featurestory
DoD for a iterationsprint DoD for a release
definition of doneDoD is informed by the reality
What kind of DOD we can have
Code is readable it documents itselfJavaDoc and inline comments are entered
Code is refactoredCode obeys clean code principles
Code obeys naming conventions and indentation rules
definition of doneNot a good idea since DOD items should be verifiabledemonstrable
Clean Code Principles as DOD
Clean Code Principles are already a must
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
DoD for a task DoD for a featurestory
DoD for a iterationsprint DoD for a release
definition of doneDoD is informed by the reality
What kind of DOD we can have
Code is readable it documents itselfJavaDoc and inline comments are entered
Code is refactoredCode obeys clean code principles
Code obeys naming conventions and indentation rules
definition of doneNot a good idea since DOD items should be verifiabledemonstrable
Clean Code Principles as DOD
Clean Code Principles are already a must
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
Code is readable it documents itselfJavaDoc and inline comments are entered
Code is refactoredCode obeys clean code principles
Code obeys naming conventions and indentation rules
definition of doneNot a good idea since DOD items should be verifiabledemonstrable
Clean Code Principles as DOD
Clean Code Principles are already a must
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
definition of doneWhat can be the Dod entries
DOD for Tasks DOD for stories DOD for Sprints DOD for releases
Unit tests are writtenCI default builds are green Integrationacceptance
tests are writtenDesignanalysis documents
are written
No critical bugsCode is reviewed by peers
Demo scenarios are created
All CI builds are greenNo major amp critical bugsCode coverage calculated
SIT is done
Performanceload tests are completed
Release notes are preparedCutover 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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
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 sectionssplit the review into
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
must-havessection of the review meeting
Focuses on stories having business valueAudience does not expect to have too much technical detail
Acceptance criteria should passThe product should be potentially shippable
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
must-havessection of the review meeting
Technical Dept(If itrsquos worth mentioning to stakeholders)
FeaturesStories with Demo(The ones the team commited to delivering)
MajorCritical 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 meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
section of the review meeting
No need to have stakeholders in the meetingTechnical details could be reviewed
Focuses quality of implementation and support
should-haves
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
section of the review meetingshould-haves
Success Rates of Continuous Integration Builds
Support CasesAvailable Bugs
TestCode Coverage
Release NotesChange 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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
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 agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
The meaning in agilehow it should be heldrecommendations
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
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
ProblemDemoReview 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
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
Doing a simulation of the review for complex stories before the meeting will make the team be sure about the software
ProblemSoftware 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 roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
Focus on reviewing what has done and do not go off the roadPre-reviews by product owner should be done by the team
Team should be prepared for the reviewAllowing too many external audience might cause to exceed the timebox
ProblemMeeting exceeds timebox
recommendation
Letrsquos 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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
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 POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
Whenever a story is completed (or almost completed)ask PO to spend few minutes to review all the details
Pre-review with POIt 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
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
ProblemToo much technical discussions
recommendationDoD should cover quality standards
Technical details should be clarified in the sprint before the meeting
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
ProblemSome people are talking the others are sleeping
recommendationEveryone should participate in the meeting no excuse
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
ProblemPeople are not following the meeting just surfing and chatting
recommendationInternet should be closed in cellphones and laptops
Mails should be checked on breaksOnly urgent calls are allowed
These rules should be mentioned in the beginning of the meeting
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
ProblemThe team is cheating on what is done and not done
recommendationTrust is a must
Everything should be transparent including the failuresNo blaming no finger-pointing
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
ProblemChaos in the meeting
recommendationShow agenda to the team and the progress of the meeting
Remind the rules of review meetings to the team
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
ProblemToo much negotiation with the Product Owner
about accepting the stories
recommendationAcceptance criteria should be defined in advance
DoD should be checked by team in advanceAll parties should be positive and objective
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
ProblemThe team gives status reports to Product Owner
recommendationIt is not a status report of individual team members
It is not a what I did in the last sprint discussionIt is not a status meeting
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
ProblemStakeholders are bored
recommendationFocus on the demo and avoid going into too much detail
Separate the meeting into two sections
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
ProblemProduct Owner changed its mind about the predefined
acceptance criteria during the review
recommendationToo 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 slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
Photos used in the slidEShttpwwwflickrcomphotostherahim5587920310httpwwwflickrcomphotosmesfoto4245156422httpwwwflickrcomphotoskeysring3493912575httpwwwflickrcomphotosbealluc158962685httpwwwflickrcomphotosunclefuz4506302304httpi48tinypiccom2saghhsjpg
ReferencesDefinition of Done httpwwwscrumallianceorgcommunityarticles2008septemberwhat-is-definition-of-done-(dod)httpwwwagilistanbulcom201212definition-of-done-nin-gucuhtml
Big Bang Iterative Incremental Agile httpavailagilitycouk20091222fidelity-the-lost-dimension-of-the-iron-triangle
Acceptance Criteria httpwikiservicenowcomindexphptitle=Well-Written_Scrum_StoriesStory_Acceptance_Criteria
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom
Lemİ orhan ergİnlemiorhanagilistanbulcom
lemiorhan
lemiorhan
agilistanbulcom
lemiorhan
LINKE
DIN
TWITT
ERSL
IDES
HARE
BLOG
Principal Software Engineer SonyFounder amp Author agilistanbulcom
flyingtomooncom