From our user's feedback it became obvious that it is not enough to have only one "Completed" status. We were advised that in real world there are two completed states for a task. One is when a developer considers the task as completed and another is when QA team or product owner approves it.
Two common use-cases are:
- the bugfix is deployed in production;
- QA team has checked the change or product manager verified the task.
Last week we've added this missing state and called it "Verified". We considered three possible names for this status. Our users' suggestions were "Accepted", "Released" and "Verified". "Accepted" was declined because of possible confusion between "Accepted" and "Assigned" statuses. The later is often used in bugtrackers to represent the case when a developer accepts the task or assigns it to himself or to another developer. We also thought that "Released" name does not cover the second use-cases for the completed status, so we decided against it as well. We decide that "Verified" has the best possible semantics.
From the application point of view, "Verified" task is treated exactly as Completed. For instance, status change from completed to Verified affects neither burndown nor prediction nor progress reports. "Closed" task filter now shows both verified and completed tasks.
Speaking of semantics, we found that Acunote users most of the time were using "Deferred" status not to indicate the task is really deferred, but rather to mark it as blocked. Therefore we decided to rename "Deferred" status to "Blocked" and adjusted application behavior. Deferred used to affect remaining time, Blocked does not. In a sense, Blocked task becomes a special case of task In Progress which can not be continued for some reason.