Checkpoints represent the point in a project where the relative complexity is at it's lowest. These are ideal stopping points where it is easy to step back into a project having a long break. The key is that Checkpoints must be worked until completion before moving to a different Checkpoint. This prevents the 'I worked all day but got nothing done' syndrome.
Checkpoints are usually one sentence, written in past tense, describing a future state of low complexity.
Project complexity can be thought of as the time it takes to describe the current state. The longer it takes to tell someone else where you are, the more complex of a state it is in. This normally represents the completion of tasks but isn't directly analagous.
- A high complexity state would be, "I am adding a new table to the database, and have created 2 out of the 5 foriegn keys and only 1 of the 3 new columns we need. I haven't begun adding the columns the code base yet."
- A lower complexity state would be, "I have added the keys and columns to the database, but haven't added it to the code yet."
- A low complexity state would be, "I have changed the database and code."
Agile-esque User Stories may break down features into logical and technical steps forward, but completing a User Story may not be at a place of low complexity.
Since Checkpoints are set in the future, once you can actually say a checkpoint then you've actually hit it.
Writing "I have completed database integration." may seem weird when you're about to start the integration, but as soon as you can say those words then you know you've completed your Checkpoint and are ready to move forward.
Checkpoints can be prioritized, but it certainly isn't required. Once a Checkpoint is complete, you have the freedom to move to any other Checkpoint from any other project you wish -- knowing that coming back will be very easy.