When a project start usually a number of risks presents itself. These risks needs to be clarified (usually but grooming the project) by the team, Product Owner and stakeholders in coherence. To minimize the risks a breakdown of the project into epics and subsequently into user stories is necessary in order to identify the risks and deal with them accordingly.
Risks usually present themselves within (but not limited) to the following categories:
- Business Risk
- Social Risk
- Technical Risk
- Cost and Schedule
This risk is usually handled by the Product Owner in collaboration with the stakeholders. The questions is if we’re building the right thing (product/feature). Is this what brings the most outcome and value to the stakeholders?
This is an assessment of the team who have to build the product or feature. Do we have the right competences and knowledge within the team and will the team be able to divide the work in a sensible way?
Here we need to identify if our platform and infrastructure is prepared for running the new product or feature. Also we have to take a good look at if the product or feature will be able to scale (up/down) in the future on this platform.
Cost and Schedule
It’s important for the Product Owner and the Stakeholders to make sure that the product or feature will be able to be reach the customers within a certain timeframe and budget. Say, if a feature needs to be ready for Christmas it makes no sense to start developing right before Christmas. Fixed deadlines and budget usually makes it hard for the Product Owner to tweak the development phase, though he has good tools to make a solid guess based on “Yesterdays Weather” and the teams velocity.
I often see unexperienced Product Owners ignoring the risks (or unable to identify them) and often this leads to the team is unable to meet the deadline even though they keep a Sustainable Pace. However, this changes as the Product Owner become more experienced or receive training on Risk Assessment.