Scrum Practices – When to Mark a User Story as Done

agileproduct-ownerscrumuser-story

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?

Best Answer

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.