/
Poor requirements provisioning process

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

Related content

Uncontrolled scope volatility
Uncontrolled scope volatility
More like this
Absence of roadmap or vision
Absence of roadmap or vision
More like this
Poor Sprint planning process
Poor Sprint planning process
More like this
Not ready for development backlog is taken into work
Not ready for development backlog is taken into work
More like this
Poor dependencies execution
Poor dependencies execution
More like this
Product Owner is not involved enough into Sprint execution
Product Owner is not involved enough into Sprint execution
More like this