Poor requirements provisioning process
Poor requirements provisioning process, i.e. customer representative (PO/BA in case of product development) does not posses enough information to specify Acceptance Criteria
Usually caused by:
Too many stakeholders on business side
There is no single point of decision
Power is concentrated in hands of not interested stakeholder without power delegation or backup options
Discovered by combination of metrics:
Velocity: Committed vs. Completed, when team cannot meet commitments due to the fact that requirements clarified during active iteration might increase workload / scope of work not matching team's capacity
Delivery Forecast via Burn-up, when "Completed" line goes up and down (for Sprint Burn Up Scope line also fluctuates a lot)
Requirements Rewritten After Became Ready, when goes up as there are frequent updates in the "ready for development" scope in sprint backlog during active iteration
Backlog Health, when low indicating that there is no enough "ready for development" scope to fill out several future iterations
Reopened Defects, when goes up meaning that delivery team does not possess enough information/knowledge to meet expected behaviour of the product