Is it normal to occasionally have two milestones with the same completion date?

Question

I'm developing a list of milestones for a hypothetical software development project.

Two of the milestones I've come up with are:

  MILESTONE              DUE DATE    STAKEHOLDER   ACCEPTANCE CRITERIA
-------------------------------------------------------------------------------
3 Development completed  15/05/2012  Development   All development tasks have a 
                                     team          status of 'Done'.
4 System tested          15/05/2012  Testing team  Intranet system fulfills all 
                                                   of the test cases.

I've given both milestones the same completion date, as I can't see how one activity can be complete independently of the other.

If development is complete, then testing must be also, because testing might reveal errors which required further development to resolve.

If testing is complete, then development must be also, since the fact that the system is fulfilling all of the test cases means that the software is doing its job, hence no further development is required.

Does this seem normal? Or is there some mistake in the milestones I've defined?

(Parenthetically, do the milestones seem to break the SMART criteria in any way? Personally I think they are fine, unless I'm misinterpreting the SMART criteria somehow.)

Answer 1

Generically speaking, there is nothing ever wrong with two, or more, milestones finishing together. In some cases, the logic says they MUST finish together, in which case you would create a FF (finish-finish) constraint.

The logic you state above makes sense, too; however, (and I am reading into this as we do not have insight into the rest of your schedule) you may have your decomposition at a level of abstraction that you lose sight of when work is triggered, i.e., how is the testing activity triggered and when will you know the testing activity is starting late?

If the decomposition is too abstract, you may not know your testing will be late until it is actually late. If you are monitoring your schedule, forecasting, and predicting performance, you want to know way before that. So creating the next level down where you have initial development, then testing, then subsequent development for fixes, enhancements, etc., could serve you well for schedule control and prediction.

Answer 2

While your approach is possible. It may be better to define development done as Ready for Testing. This should have development completing ahead of Testing.

You will need an additional item for Defects Resolved. It has been my experience that test failures fall in to three categories. Only one of these categories would require work on the code.

• Application failure, incorrect code.
• Test failed when it should have passed.
• Incorrect requirements.

While it may be preferable not to release code with bugs, it is frequently done. If testing discovers bugs which are not going to be fixed before release, then the code released to testing can be considered done. These bugs should be recorded as known defects. (It was common for Unix man pages to contain a Bugs section listing cases which would fail. For instance, awk would fail on lines larger than 1024 characters.)

Even if you are following a zero defects approach, I would argue that you may still need to release with known bugs.

Once development is complete, you may want a maintenance resource in place to repair any bugs found in testing or after release. This can be the original development team if they are working on the next release of the product. It that case, make sure bugs are fixed appropriately in both releases. This may result in two different bug fixes, but often the same fix can be applies in both releases.