Search code examples
project-managementagileprojects-and-solutionsscrumagile-project-management

How to measure project completeness?

Are there any formal/informal measures of comparing completed functionality vs initial requirements of a project. Specifically, my goal is to identify any missed requirements early on in a project. Having gone through many agile/scrum methodology articles and books, one way to do this would be a requirements review during a "sprint review" but I was wondering if there were any other techniques/tools out there.

Thanks,

Solution

  • Are there any formal/informal measures of comparing completed functionality vs initial requirements of a project.

    The word(s) you are looking for is "Done Criteria". It has a more deeper meaning than the words itself, in the Agile world. It is often the first thing to be fixed in an Agile Organization, if it is found to be missing. Below (at the end) is a link to an article which explains it in more detail.

    Most Agile Teams use User Stories as their "initial requirements". The user story would be your initial requirements which would be just enough to get the Team started. The measure used, should be what most Teams call, "the Done Criteria". Every User story should have a done criteria. For eg. In order to call a backlog done, these list of things need to be Done. While setting this we do not worry about How it would be done, only What needs to be done.

    During the Sprint Review, the Team would do a show and tell of the working software, and if it meets the done criteria, the PO should approve it to be officially marked done.

    Off course, sometimes User stories have changing Done criteria, especially for new Teams or Projects, but that is perfectly normal, because a sign of a good user story is that it is negotiable. The Done Criteria can be slightly modified after getting approval of Team. Teams rarely disapprove these, unless the change causes a dramatic increase in complexity of the work to be done.

    So to summarize:

    Initial requirements i.e. User Stories need to have a "what" needs to be Done Criteria". If something is missed and discovered during the Sprint the PO may change the Done Criteria of a User Story after getting an approval from the Team.

    During Sprint Reviews the working software can be measured against the Done Criteria, and if it measures up, the User Story can be called done.

    http://scrumalliance.org/articles/105-what-is-definition-of-done-dod