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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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