Comments on: “Done” = “I am proud of it” http://missioncontrol.itteco.org/2010/01/27/%e2%80%9cdone%e2%80%9d-%e2%80%9ci-am-proud-of-it%e2%80%9d/ Project Tales & Lesson Learned by Itteco Scrum Masters Sun, 25 Apr 2010 13:05:19 +0000 http://wordpress.org/?v=2.8.4 hourly 1 By: Ivan Paramonau http://missioncontrol.itteco.org/2010/01/27/%e2%80%9cdone%e2%80%9d-%e2%80%9ci-am-proud-of-it%e2%80%9d/comment-page-1/#comment-13 Ivan Paramonau Mon, 01 Feb 2010 20:15:47 +0000 http://missioncontrol.itteco.org/?p=57#comment-13 'Done' is function of time. What was <a href="http://en.wikipedia.org/wiki/Moon_landing" rel="nofollow">'Done' back in July 20, 1969 and was watched by 500 mln people</a>, isn't really considered persistent. The same is true with "I'm proud of it". And that's ok. DoD as I see is meant to minimize re-work on the forthcoming sprints, and Feel Proud would do better than Deliverable, in my experience. Re-work has to be handled via velocity expectations. Provided that sprints are rolling, the velocity of previous sprint (where you have had re-work as well) should indicate what velocity should be planned for the next sprint. The model is self-adjustable. ‘Done’ is function of time.

What was ‘Done’ back in July 20, 1969 and was watched by 500 mln people, isn’t really considered persistent.

The same is true with “I’m proud of it”. And that’s ok.

DoD as I see is meant to minimize re-work on the forthcoming sprints, and Feel Proud would do better than Deliverable, in my experience.

Re-work has to be handled via velocity expectations. Provided that sprints are rolling, the velocity of previous sprint (where you have had re-work as well) should indicate what velocity should be planned for the next sprint. The model is self-adjustable.

]]> By: Yury Kusik http://missioncontrol.itteco.org/2010/01/27/%e2%80%9cdone%e2%80%9d-%e2%80%9ci-am-proud-of-it%e2%80%9d/comment-page-1/#comment-12 Yury Kusik Mon, 01 Feb 2010 14:15:34 +0000 http://missioncontrol.itteco.org/?p=57#comment-12 There's an interesting case about planning aspects of "done" items (e.g. user stories in scrum). Let's have a look on following case: * we consider item A done at the end of iteration X (as in "i'm proud of it - let's ship it"), * after the iteration X we calculate its velocity as a sum of done items' estimates, * during later stage we discover some defect about item A, so our opinion about item being done changes ("we aren't proud anymore"), * so we should adjust our plan to fix item A in current or further iteration. The question is if we should change the status of the item A to "not done" and therefore decrease velocity of iteration X ("we thought we have done A, but in fact we haven't")? What if the bug is tiny in comparison to the whole amount of work, but it anyway prevents us from "being proud"? There’s an interesting case about planning aspects of “done” items (e.g. user stories in scrum). Let’s have a look on following case:

* we consider item A done at the end of iteration X (as in “i’m proud of it – let’s ship it”),
* after the iteration X we calculate its velocity as a sum of done items’ estimates,
* during later stage we discover some defect about item A, so our opinion about item being done changes (”we aren’t proud anymore”),
* so we should adjust our plan to fix item A in current or further iteration.

The question is if we should change the status of the item A to “not done” and therefore decrease velocity of iteration X (”we thought we have done A, but in fact we haven’t”)? What if the bug is tiny in comparison to the whole amount of work, but it anyway prevents us from “being proud”?

]]>