Scrum PSD Practice Test - Questions Answers, Page 4

Releasing the product at the end of the sprint doesn't relate to one item and when it's done. Code coverage does, but it's the worst criteria in this list, because it's a stimulus to write tests that cover a lot of lines rather than cover the functionality.

The other two are good metrics. Function points are the points representing the amount of business functionality.

It's definitely a good practice. And not because you can see the code coverage (which also isn't an excellent metric of quality and progress), but because you can detect problems before moving on.

There is no sprint 0, architecture won't take care of itself and there is no architect role. The architecture is an ongoing discussion and growing construct. There are guidelines and principles in place.

An architecture spike is a small development activity to learn about technical elements of a proposed solution.

Technical debt is the result of incomplete work going into the increment and poor design and architectural choices.

Hiding the bug won't make it go away. Discussing with the product owner is a good step to take, because he knows what work leads to maximum value.

if the documentation is adding to the quality and maintenance of the software this is definitely a good argument for documenting every sprint. Just because that's the way it's done and we don't want change is not a good reason. Tooling that requires is also isn't. And the scrum master cannot demand this kind of things. If the company's definition of done says so, you must :)