How to Define the part of DONE

Are you referring to the Definition of Done? If yes, then this should be created within the Scrum team, unless there is, of course, an organizational one that you'd need to follow. But then again, is an org one exists, you guys could also create one that's more stringent than the org DoD.

Note the DoD refers to the whole sprint increment. The user stories would use something like Acceptance Criteria, or User Acceptance Criteria, or Gherkin scenarios, etc, and these would be specific to each story (or, with small variations, to group of very similar stories).

I believe we cannot define a "Partial Done" item, any sprint backlog item is NOT considered done unless its DONE DONE (which will include Development, testing, documentation (just enough), etc...)

Every item in the sprint backlog will have a definition of done and the entire increment will have a definition of done.

Every item in the sprint backlog will have a definition of done and the entire increment will have a definition of done.

>> Is it necessary that each sprint backlog item will have the same DOD as that of an increment?

I believe we cannot define a "Partial Done" item, any sprint backlog item is NOT considered done unless its DONE DONE (which will include Development, testing, documentation (just enough), etc...)

The tendency to overcomplicate never ceases to amaze me.

SBIs are either "done" or "not done". There's no such thing as "done done" - what does it even mean? Note that some items would require development only (no testing!), or development + testing, or no development at all.

Furthermore, SBIs are either done or not done when judged against their own acceptance criteria (note: some SBIs don't even have acceptance criteria!), not against the increment's definition of done.

Every item in the sprint backlog will have a definition of done and the entire increment will have a definition of done.

Not really. Most sprint backlog items will have individual acceptance criteria, while the increment will have a single definition of done (even when there's another dod at the organizational level, there'll still be only one DoD at team level; the team level one will, surely, incorporate the organizational DoD and add stricter quality terms, for example).

Every item in the sprint backlog will have a definition of done and the entire increment will have a definition of done.

>> Is it necessary that each sprint backlog item will have the same DOD as that of an increment?

What do you think? 

When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this may vary significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.

I'd argue the above paragraph could use some refactoring :)

SBIs are either "done" or "not done". There's no such thing as "done done" - what does it even mean? Note that some items would require development only (no testing!), or development + testing, or no development at all.

Furthermore, SBIs are either done or not done when judged against their own acceptance criteria (note: some SBIs don't even have acceptance criteria!), not against the increment's definition of done.

>> I think you mean PBIs here ( as per the guide ;-) )  

What do you think? 

When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this may vary significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.

I'd argue the above paragraph could use some refactoring :)

>>As per me its not necessary that the PBIs will have same DOD as that of an increment. I would also recommend to have the DOD at the increment level as at the end increment as a whole is released not individual PBIs. Agree with you to use acceptance criterias for PBIs as they can be totally different from each other.

My only intention with the question was to bring this focus to light , thanks for putting it up :-)

I'm going to use an example completely outside of software. 

I have a team of people that are going to build a house.  Our ultimate goal is to have a 3 bedroom, 2 bathroom, family room, kitchen, laundry room, patio, and 2 car garage.  We have a floor plan that shows the layout of the rooms as well the dimensions of each room.  All of the work done to build the house must adhere to the construction companies standards and all municipality building codes. (In Scrum terms the house is the story, the details of the house layout are the acceptance criteria. The overall work description above is the Epic. The municipality building codes would be the organizational DoD while the construction company standards would be an additional organizational DoD)

The team then breaks up the work into units of work.  They create a plan to build the foundation for the home. They create a plan to build the frames that will support the walls and roof as well determine the boundaries of each room. They develop a plan to build a roof. They develop a plan to finish the insides of each room. For each of these plans they will determine all of the requirements that must be met to say the work will satisfy the building codes for the municipality in which the work is being done and the standards of the construction company. (Again in Scrum Terms, each "plan" is a separate user story and some of them could actually be sub-Epics that need to be decomposed further.  The requirements they determine per story will be the acceptance criteria. The methods of determining code compliance and standards of the construction company would be included in the Team's DoD in addition to any standards for which they want to hold each other accountable to.)

It goes on and on for every level of which the work can be decomposed.  Each individual unit of work(story) is determined "done" when it has met the acceptance criteria.  The combination of like stories (Sprint increment) is determined "done" when all stories are "done" and the DoD is satisfied. This combination of stories will be producing potentially releasable increments (can't sell a house that only has a frame erected) and the totality of the increments will produce a releasable increment (fully constructed house). 

Does this help at all?