Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

There is a notion in scrum that emphasizes delivery of workable units at the end of each sprint. Each workable unit also maps directly of indirectly to a user story and when in new sprint PO introduces new PBI (new user stories), this means that practically team can't always go back to previous user stories to do the rest of the job, which in turn means that when you implement a user story, you should do it as complete as it's known to the team in that time, and you shouldn't forget anything (something like "I'm sorry, I've forgotten to implement validation for that input control" or "I didn't know that cross-browser check is part of the user story"). At the other hand, test, backward compatibility, acceptance criteria, deployment and more and more concepts come after each user story.

So, when can team members know that the user story is done completely, not just for demo, and start a new one?

share|improve this question

4 Answers 4

up vote 15 down vote accepted

You define the definition of done. But it should include everything to make it completely done. "I'm sorry, I've forgotten to implement validation for that input control" means your story is not done, so should it put back in the in progress column. If you discovered that after the sprint, it's a bug that the PO can address (or not) in the next sprint. The PO eventually decide if you ship the product at the end of an iteration.

Like you said, testing comes after code has been written for a given user story. But testing should be a part of your definition of done.

Therefore, done completely is the state you get when a user story matches your definition of done.

share|improve this answer
    
In the perfect world, the DoD should be when all of the Acceptance Criteria pass. If they all pass and the client says it's not done, it should be noted as a new story on the backlog. However, we don't live in the perfect world, so this won't happen much I guess. –  Jan_V Jul 30 '11 at 13:18
    
Disagree with @Jan_V's statement above. DoD is not the same as acceptance criteria - see the 'definition of done' article that Pierre 303 posts above and the Summary: "The definition of done is orthogonal to user acceptance criteria" –  bacar Dec 21 '11 at 12:04

Besides code reviews, a definition of done and the definition of high level acceptance criteria that a user story has to pass in order to be completed, we also have a review at the end of each sprint, where the stories are presented to a broader community in our company ( first and second level support, consultants, sales persons and so on), because they usually have a deeper domain knowledge.Only after a story passes this review it is treated as completed.

share|improve this answer

First, where I work the tasks such as test, acceptance criteria, code review are part of user stories..

Second, user story is done when it is ACCEPTED by PO. PO reviews a story for acceptance as soon as team marks it as COMPLETE. If the PO doesn't accept the story then the team would likely add more tasks.

And yes you are right team should complete the story as per the scope agreed during spritn planning. However, scope and time-boxing doesn’t go together so the team after discussing with PO can always downsize the scope for the story - to a level where it can be completed within the iteration.

Whatever is the agreed scope, story should not be marked COMPLETED if there are known issues - however it can still be accepted by PO at the end of iteration e.g. may be the remaining bugs are not critical or frequent.

share|improve this answer
  1. Definition of done, per story, is the unique and certain differentiator between doing and done for a story. It's usually a short sentence that describes what to do to verify that the story is done.
  2. If a story is considered done according to its definition of done, it means that it is done.
  3. If something related to a previous done story is later found still to do, then a new story for that something is created with its new definition of done.
  4. The new story is added to the backlog as any other, so that it will undergo the standard scrum flow.
  5. Over time, definitions of done will improve, as well as the ability to read between their lines, thus reducing misunderstandings.
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.