1

Identify a Subset of the Quality of Service Requirement List

• Open the quality of service requirements list on the project portal. For each of the highest priority quality of service requirements, determine the appropriate developer or development group to provide an estimate.
• Trace the quality of service requirement to affected scenarios if applicable.
• Provide estimates for enough of the highest priority quality of service requirements to allow for large and small scenario options by the business analyst.
• Provide estimates for enough quality of service requirements to encompass approximately twice the number of ideal person days in an iteration.

2

Create Implementation Estimates

• Work with the developers to do a rough order of magnitude estimate (ROM) of the complexity of each quality of service requirement. Many projects can use the following heuristic. If the work item requires a half dozen or less 1-2 day development tasks to implement, choose 1. If the work item requires between a half dozen and a dozen 1-2 day development tasks to implement, choose 2. If it is larger than this, choose 3 and consider splitting the quality of service requirement. It is important to keep the rough order of magnitude estimates relative. That is, a quality of service requirement with a rough order of magnitude of 2 should be approximately twice as big as another with a ROM of 1.
• Use a rough order of magnitude of 0 for trivial scenarios. Group together these smaller work items until they are big enough to be a 1.
• If further elaboration is necessary, work with the business analyst and the developers to add more detail to the quality of service requirement. Revise the rough order of magnitude estimate if needed.
• Resynchronize the quality of service requirements list to publish/reflect these estimates.

3

Identify Constraints

• Work with the developers to identify risks that can delay or prevent successful completion of the work required for realizing the quality of service requirements, such as knowledge deficiencies and third-party software dependencies. If a new risk work item is created, attach risk work items to the quality of service requirement to show the relationship.
• Document any special needs that a quality of service requirement might have. Look for potentially overloaded developers or dependencies that might affect the scheduling. Additionally, consider the architectural impacts. Note any impacts in the description of the quality of service requirement.

The highest priority quality of service requirements in the quality of service requirements list have estimates that indicate the complexity.

The updated quality of service requirements list is published to the project portal.

Special resources, risks, or constraints associated with realizing a quality of service requirement have been communicated within the work item or with attached work items.