Which two statements explain why the definition of done is important to the product owner?

I have a conflicting view on the answer to this question which appears in the scrum.org open assessment for PSM I.

Which two statements explain why the definition of "Done" is important to the Product Owner?

A)It assures the Increment reviewed at the Sprint review is usable so the Product Owner may choose to release it.

B)It helps the Product Owner track the open work during a Sprint.

C)It creates transparency regarding progress within the Scrum Team.

D)It identifies undone work that can be addressed in a separate Sprint.

I feel the answer is A & D as I believe the DoD tells whether a backlog item has been completed or not. If not, it has to be addressed in a separate sprint.

However, the actual answer provided is A & C. I am not sure how C is more relevant than D. 

Apologies. The above question appeared in the PSPO I open assessment (not in the PSM I assessment as mentioned in OP).

A team plans to complete work in a Sprint, and not to defer completion until a later point. Why then would it be useful to identify undone work for the purposes of addressing it in a separate Sprint?

Thanks Ian.

My question is more of a comparison between options C & D.

To rephrase, how does DoD ensure "transparency regarding progress within the Scrum Team"?

If it's clear what "done" means, then you also have clarity over the work that must be performed for an increment to be of release quality. As long as the increment in development falls short of that standard, then there is clearly still work to be done. That's the transparency.

Some teams create tasks for implementing each criterion in the DoD, so the progress of work can be explicitly gauged on a Scrum board and/or task burndown

Thanks Ian. That's a bit of a convoluted answer to an outsider who has not worked on scrum projects. But I'll take that as the final answer.

To me, if a PBI meets criteria in DoD, then it's accepted as completed. Otherwise not. This is what option 'D' says. This is also what you say to some extent  - "As long as the increment in development falls short of that standard, then there is clearly still work to be done".

As you're limited to two answers, I suppose answer C encompasses answer D.  Therefore, answer D is the most correct answer.

Hi Ian,

People seem to be ambiguous about the answer to this question. Is there some way we can get a final consensus on this? 

I feel quite stupid, and wish I could edit my post...  this is what I meant to say:

As you're limited to two answers, I suppose answer C encompasses answer D.  Therefore, answer C is the most correct answer.

I think that C is more relevant than D because C creates transparency and transparency is one of the three pillars that uphold every implementation of empirical process.

Undone work, on the other hand, is only useful at the Sprint Review:

The Product Owner explains what Product Backlog items have been "Done" and what has not been "Done"

While I agree that A & C are the right answers, I understand the confusion regarding answer D.

Does "undone work" mean work that was reverted? If so, answer D does not make sense.

However, "undone work" can also mean work that is not done or not complete, in which case answer D does make sense as the DoD would identify such work due to which the PBI does not meet the DoD.

Hello,

Let me explain answer C) with an example: It creates transparency regarding progress within the Scrum Team.

to understand the answer let me create one sample DoD:

1) Wiki Written: Yes/No

2) Wiki Review: Yes/No

3) Test Case Written: Yes/No

4) Test Case Review: Yes/No

5) Code Review Done: Yes/No

6) Testing Done: Yes/No

etc. etc.

So, from time to time team will update this Yes/No into the DoD checklist. So, if any external person will see the user story/requirements, he can easily know the progress of that user story. 

Also, it maintains the quality of the user story. If all are "Yes" then we can ensure that all checklists are done and now it's ready for release also.