Task Complete Definition

(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