Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Creating a definition of "done" #8

Open
sankarshanmukhopadhyay opened this issue Sep 15, 2016 · 14 comments
Open

Creating a definition of "done" #8

sankarshanmukhopadhyay opened this issue Sep 15, 2016 · 14 comments

Comments

@sankarshanmukhopadhyay
Copy link
Contributor

As the project moves through the stages of completing chunks of tasks and making features available, it would be good to have a baseline agreement on what is a definition of "done". Such a definition can be applicable at various instances - for a feature; for a story/epic or, for a release. The following lists the basic items in a check-list which can be used to arrive at the state of 'done'. This is not intended to be a static list; it is expected that it will evolve over time being driven by the needs of the project organization, focus and direction.

The definition could be expected to implement the values necessary to enhance the quality of the software produced, but may not assert a functional value of that.

Definition of Done (DoD)

A listed item will be considered as done if:

  • code, including unit tests, is merged upstream (in mainline+branch, as appropriate)
  • feature has passed all integration gates
  • feature is available as a packaged bundle
  • test plan is completed; documented; reviewed; signed off
  • test plan is implemented in CI or, automation
  • feature is integrated with install, tear-down or, CRUD as appropriate
  • feature passes automated tests/tests in test plan
  • documentation/notes for the feature in functionality is available to content author
  • no major, critical defects including data loss inducing ones have been introduced
  • performance regression has not occurred, if applicable
  • a completed feature is accompanied with a recorded demo
@japplewhite
Copy link

This looks great - very ambitious but if adhered to will produce an excellent result.

I might simplify the line
"no major, critical defects including data loss inducing ones have been introduced"

to read
"no known defects have been introduced"

@julienlim
Copy link
Member

It looks like a good start. I would like to suggest adding the following:

  • Code has been produced against all user story task items (JIRA issues) and acceptance criteria has been met
  • Code is commented, checked in, and builds without error
  • Work has been peer reviewed
  • Code is deployed to system test environment and integration testing is passed
  • Code passes QE testing
  • Any build/deployment/configuration changes have been documented
  • Relevant documentation and diagrams are updated and posted in document repo
  • Initial UI design (if applicable) which may include visual design and/or assets is completed and linked to JIRA
  • UI design has been reviewed and agreed-to by key stakeholders
  • UI design has been sent or merged upstream
  • For Future: usability testing may become part of the DoD in the future
  • Product Owner accepted the user story (JIRA Issue)
  • Customer facing documentation is complete -- we may want to not include this in the DoD

@nthomas-redhat
Copy link
Contributor

Looks Good.
Do we really need to add the documentation part as part of DoD?

@mkudlej
Copy link

mkudlej commented Sep 16, 2016

Looks good to me, please add compilation of previous 4 comments as document in documentation.

@sankarshanmukhopadhyay
Copy link
Contributor Author

@julienlim - it would seem that the project could use the list in your comment as opposed to adding to the first proposal. @brainfunked, I'll wait for a review from you before I go ahead and do a PR

@julienlim
Copy link
Member

I forgot one more comment which is that we need to figure out and clearly state that in order to complete the user story / feature, whether or not it requires that the API, CLI, and UI are all completed (coded, tested, no critical and major bugs, etc.). In my past experience, all 3 had to be met before DoD was met. In cases where we didn't want to have it hold up the DoD, we had 3 separate user stories for API, CLI, UI respectively in order to properly chunk the work and fulfill the DoD, so the user stories would meet the DoD, but the overarching epic that contained all 3 would not be completed until the underlying API, CLI, and UI user stories were completed.

@japplewhite
Copy link

Hi All - I compiled the suggestions thus far with an edit for docs - complete at the epic level. This list seems a bit unwieldy - I like thoroughness but I wonder if we have a bit of scope creep here. Can we sharpen our pencil as to what will be practical?


A listed item will be considered as done if:

  • code, including unit tests, is merged upstream (in mainline+branch, as appropriate)
  • feature has passed all integration gates
  • feature is available as a packaged bundle
  • test plan is completed; documented; reviewed; signed off
  • test code is implemented in CI or, automation
  • feature is integrated with install, tear-down or, CRUD as appropriate
  • feature passes automated tests/tests in test plan
  • documentation/notes for the feature in functionality is available to content author
  • no known defects have been introduced
  • performance regression has not occurred, if applicable
  • a completed feature is accompanied with a recorded demo
  • Code has been produced against all user story task items (JIRA issues) and acceptance criteria has been met
  • Code is commented, checked in, and builds without error
  • Work has been peer reviewed
  • Code is deployed to system test environment and integration testing is passed
  • Code passes QE testing
  • Any build/deployment/configuration changes have been documented
  • Relevant documentation and diagrams are updated and posted in document repo
  • Initial UI design (if applicable) which may include visual design and/or assets is completed and linked to JIRA
  • UI design has been reviewed and agreed-to by key stakeholders
  • UI design has been sent or merged upstream
  • Product Owner accepted the user story (JIRA Issue)
  • Customer facing documentation is complete at the Epic level

@sankarshanmukhopadhyay
Copy link
Contributor Author

Alright. I tried to group things logically so that a set of granularity can be achieved. I've, perhaps needlessly, broken it down into code-base, feature and UI related topics (this was partly based on Ju's comment and the understanding that some items might not have the requirement for everything).

@brainfunked - needs your review before we mark this up and commit. No gains in spinning more wheels on this.

A listed item will be considered as done if for a story accepted by the Product Owner (in the form of a JIRA issue)

Source code for the feature

  • has comments
  • has been reviewed
  • is checked in
  • builds without errors
  • along with unit tests is merged upstream in mailine and branches

which leads to Feature that

  • passes all integration tests
  • has been tested and accepted by QE vide defined acceptance criteria and test plan
  • is integrated with install, tear-down or, CRUD as appropriate
  • has documentation for the functionality is available as notes
  • has no defects which have been introduced
  • has no performance regression present, if applicable
  • has a recorded demo

which ensures that the UI

  • design has been reviewed and agreed upon by the stakeholders
  • design has been merged upstream

@brainfunked
Copy link
Contributor

@sankarshanmukhopadhyay Looks good, please send a pull request.

@r0h4n
Copy link
Contributor

r0h4n commented Jan 23, 2018

@mbukatov I am restating the definition of done based on our discussions in past week, please comment

Source code for the feature

  • has been reviewed
  • is checked in
  • builds rpm without errors
  • along with unit tests (40% coverage per PR) is merged upstream in mainline and branches

which leads to Feature that

  • passes all integration/functional tests as a gate in PR itself, if not then at least pass through manual testing once.
  • has been tested and accepted by QE vide defined acceptance criteria and test plan
  • is integrated with install, tear-down or, CRUD as appropriate
  • has documentation for the functionality is available as notes and specs
  • has no defects which have been introduced
  • has no performance regression present, if applicable

which ensures that the UI

  • design has been reviewed and agreed upon by the stakeholders
  • design has been merged upstream

@r0h4n
Copy link
Contributor

r0h4n commented Jan 23, 2018

@Tendrl/tendrl-core @Tendrl/tendrl-qe @julienlim Please comment

@julienlim
Copy link
Member

julienlim commented Jan 23, 2018

@r0h4n Ack. Not sure what you mean by "design has been merged upstream."

Are you suggesting that we commit the design files (source) into a GitHub repo and follow the review process in GitHub (vs. using Invision today)?

Please clarify.

@Tendrl/tendrl-core @Tendrl/tendrl-qe @mcarrano @gnehapk @cloudbehl @a2batic

@r0h4n
Copy link
Contributor

r0h4n commented Jan 24, 2018

Simply linking to the invision design from the spec file should be enough. Any other suggestions?

@julienlim
Copy link
Member

@r0h4n Link to Invision design from Spec file works for me. Pls. update the updated DoD accordingly. Thanks.

@Tendrl/tendrl-core @Tendrl/tendrl-qe @mcarrano @gnehapk @cloudbehl @a2batic

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants