Managing Product Development

One of the problems I see in projects is that there is not a sufficient definition of done. For agile teams, it’s not clear what done means for a timebox. For non-agile projects, the team may not agree on what done means for a milestone or for a release.

For an agile team, do you know what done means for your timebox? Is all the code tested? By whom? Is it all checked in? Does it build without problems? Can you demo the product? Can you release the product? I much prefer product that is developed, fully tested by developers, system tested by the testers, and could be released–what I call release-able. But that might not fit for your project. If the product is only demo-able, make sure everyone knows that you still have technical debt and will need another timebox for testing and fixing.

For every team, develop release criteria. That way you’ll know what done means for the project as a whole.

For a team using any lifecycle other than agile, make sure you have interim milestones and criteria for those milestones, so the team has early feedback about the project’s progress. And, measure your progress towards your release criteria.

Want to make sure you complete your project as early as possible? Define release criteria. Release criteria are the few critically important objective criteria that define what “done” means for your project. Sometimes, it’s a combination of date, defects, and feature completion. Sometimes it’s just the date. The formula for defining release criteria is:

1. Define project success.
2. Define what’s critically important that this project accomplish.
3. Draft release criteria that are: Specific, Measurable, Attainable, Relevant, Trackable.
4. Gain Consensus on the criteria from management and the project team.
5. Manage the project to the criteria.

Easy to describe, not always easy to do. Read more about release criteria here. For ideas about what to consider measuring, remember the six sides of the project.