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

Recommendations: 

  1. Improve requirements and backlog management

  2. Introduce or enhance stakeholders management incl. engagement

  3. Introduce or enhance methods of work