(a.k.a.
BinaryMilestone)
A definition on what it means to have truly
completed a task at a specific project.
Problem:
Everyone has their own opinion on what it means to have finished a task. Some developers will say they're finished when they have "cracked the nut" - have something working. Others will say that they are finished when their
UnitTests have green-barred and the code is checked-in. The differences make it hard for people to get a good idea of which tasks have been completed and which tasks are still to be done.
Solution:
Agree upon a written
TaskCompleteDefinition - a list of statements that must be true in order to be able to claim your task to be complete.
Effect:
Management can get an accurate picture of the current state of the project. Developers can stop coding once they have fulfilled all the requirements of the
TaskCompleteDefinition.
--
PeterAxelsson (small changes by
WikiGnome)
In effect, the
TaskCompleteDefinition, the list of statements, is a list of tests. Work being done should always be targeted at turning a "No" into a "Yes".
In XP, would passing all related
UnitTests be the definition of "task complete"? Is writing the tests part of a "task"?
No. The UnitTests for a new capability do not ensure that all of the capability has been added. The tests only ensure that the capability that has been added to date works as expected and previous capabilities have not been degraded. I think the UserStory may provide the definition of task complete.
Yes, writing the tests is definitely part of the task if you're doing XP, but passing all
UnitTests is not
TaskComplete according to me. Having all the
UnitTests
GreenBar would be a milestone on your way to
TaskComplete, however there's much more to
TaskComplete than
GreenBarred
UnitTests. You decide your
TaskCompleteDefinition together with your team members and you formalize it on a poster and put it on the wall where everyone can see it. Then you stick to this
TaskCompleteDefinition and when you estimate time for a task, you estimate along the lines of your
TaskCompleteDefinition.
There have been several occasions where developers in projects I've been a part of have had different opinions even on what a "Good"
UnitTest looks like, so it's important to discuss this
UpFront. But
TaskComplete covers much more than passing
UnitTests according to me.
--
PeterAxelsson (small changes by
WikiGnome)
The Task Complete Definition (also known as
PunchList) is the list of things which must be done before a task is considered to be done. They should be explicitly stated somewhere (though boilerplate can be used, such as "no SW development task shall be considered done until all
UserStories have corresponding
UnitTests, and all
UnitTests pass").
Without an explicit Task Complete Definition, often times a developer will report being done when the code is barely usable. Or, something will be polished and shined to the point of absolute perfection, when that is
more than required (and subsequent tasks are delayed as a result -
GoldPlating). Finally, a Task Complete Definition gives a better way of estimating the progress of a partially-complete task (but see
RuleOfThree) than guesstimates such as
NinetyPercentDone. If a developer can point to nine out of ten of the completion criteria being met, then perhaps the
NinetyPercentDone claim is true. This is still highly subjective and needs to be analyzed on a case-by-case basis. Full compliance with the completion criteria is much easier to judge; the job is either done or not done.
See:
TheyUnderstoodMe (an
AntiPattern)
CategoryScheduling,
CategoryRequirements