Sufficiently Complete - A "Done" Criterion

  1. Posted on October 10, 2008 8:27:AM by Earl Beede to Practicing Earl
  2. context, done, Management

A helpful way to think about a software project is to see the project as a series of decisions about what problem or opportunity the software will solve/implement and the solution itself. Theoretically the decisions start out large and granular and get refined and detailed as the project progresses. Code becomes that last place to make decisions before turning it over to the compiler. Of course in reality, software projects are more likely to see almost random decisions made at multiple levels of detail. At least most projects still tend to wind up at that last decision point—code.

With a serial decision making model of a software project, one criterion in defining “done” is to ask if the work item under consideration is sufficiently complete to make the decision the team or business needs to make at a particular point in time.

Here is an example. Let’s say I am at a point in the project where I need to make a reasonable commitment to the cost and duration of the project. What would need to be “done” in order for me to do that? A simple answer would be the requirements, the design, and some sort of staffing plan. But do I need all the requirements done and all the design done? Probably not. If I had

  • identified all critical features with their key non-functional criteria (maybe also critical out-of-scope features identified as well)
  • selected an overall architectural approach
  • worked out key design elements
  • secured commitment from critical staffing resources
  • created a list of top risks

I could probably make a reasonable commitment. I do not need all the requirements completed to the last dotted “i”. I do not need every part of the design worked out in advance. I do need the work to go to a certain level of depth and refinement where the information is sufficient enough to make the decision at hand.

Sufficiently complete is about creating the information needed to make decisions at different points in the project. Could I have done all the requirements work before making a cost commitment? Sure, but much of it would be nice-to-have rather than truly needed for the decision. Also, given that much of that requirements detail will be out of parity with other work detail (like design), it is highly subject to change and may mislead the decision at hand. Think of the sufficiently complete criterion as creating just-in-time information.

The question you must ask to determine if a work item on a software project is sufficiently complete is, “What decisions do we want to or need to make on this project?” The decision points are often closely related to the software development lifecycle you have chosen. For a sequential project, I might need to make a decision if the requirements are sufficiently complete to start design. On a more incremental and iterative project, I might need to decide if a story would fit within my iteration length. To make either decision, I have to do some requirements work but not all the work. The requirements work will be sufficiently complete when I can decide the story will/will not fit the iteration (and a little design work will be needed too) or that my risk at starting design on the sequential project is low enough to proceed.

Some common decisions that any project must face are

  • Why put our effort on this project rather than some other project?
  • What are the problems/opportunities do we want to address with this project (and which ones do we not want to address)?
  • Who should be a part of this project?
  • What technologies/strategies should be bring to bear on this problem/opportunity?
  • Does this project still make sense given the business case and what we know now?

And we don’t make these general decisions once but over and over again at various levels of detail or abstraction. At each questioning, some amount of work needs to be accomplished to get the information to make the decision.

Once you have found your decision points, identify what you must know in order to make that decision. When you have identified what you need to know, you then have the information to judge if your work is sufficiently complete.

Post a Comment:


Earl Beede

Earl Beede, CSDP is a Senior Fellow at Construx Software, where he designs and leads seminars and provides consulting services on early project-lifecycle practices, estimation, requirements, quality assurance, contract management, and software methodologies.

With more than 20 years experience as a quality assurance representative, systems analyst, process architect, and manager, Earl has designed and written software development processes for companies across a wide variety of industries. Prior to joining Construx, he held quality assurance and systems analyst positions at organizations that include the Department of Defense, Boeing Computer Services and Verizon Wireless.

Earl has a Bachelor's degree from the University of Washington. He is a member of the IEEE Computer Society and a past coordinator of the Seattle Area SPIN (Software Process Improvement Network).


Contact Earl