Skip to content

Instantly share code, notes, and snippets.

@patrickbrandt

patrickbrandt/RiskMitigation.md

Created August 5, 2018 21:54
Show Gist options
  • Save patrickbrandt/ab7c7e3709c1f49abab510fc67575fa0 to your computer and use it in GitHub Desktop.
Save patrickbrandt/ab7c7e3709c1f49abab510fc67575fa0 to your computer and use it in GitHub Desktop.
Download ZIP
PBP-RiskMitigation
Raw
RiskMitigation.md
Risk Mitigation
The inability to get stories “Ready” The customer's product owner is responsible for ensuring that stories have proper acceptance criteria. The delivery team is responsible for other artifacts like wireframes and design comps.

The contract could include a stipulation that a dedicated delivery team will be maintained only if the product owner is able to fulfill their obligation to provide acceptance criteria in a timely manner. Otherwise, the supplier is responsible for ensuring any other supporting documentation is provided so that coders can build the application.
Story point inflation: suppliers habitually apply the largest point value to every story Point inflation should be detected within two or three sprints. If the customer is providing proper guidance and clear requirements, then they should expect a normal distribution of point values for each sprint. A majority of the stories would be 2,3,5 points while there would be an occasional outlier at 8 points. If stories are consistently scored with large point values, then something isn’t right: either customers aren’t providing proper guidance or suppliers aren’t accurately scoring their stories.

If point inflation is happening, the customer will need to verify requirements are accurate and actionable. If the supplier is not scoring their stories accurately, a stipulation in the contract could give the customer the option of ending the engagement immediately.
The QA team is not accurately documenting bugs The supplier needs to include QA as part of their delivery process, but the customer must assume some QA function to verify that bugs are being caught. The most natural place to insert customer QA is during User Acceptance Testing. Customer QA would perform a “last pass” over features to verify that they are bug-free.
The points run out The customer should have the option to buy additional points as required. These can be bucketed by the supplier or pegged to the velocity of the team. For example: if a particular engagement ends up with a 30-point velocity per sprint, the customer can buy additional sprints in 30-point increments.
Points are left over Rare is the customer that leaves work on the table :)

For the sake of argument, let’s assume the customer is completely satisfied with their product and still has some points in the bank.

One of two options should be stipulated in the contract:
  1. Use them or lose them
  2. Rebate for points remaining
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment