patrickbrandt/RiskMitigation.md

## RiskMitigation.md

      
    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:
      
        Use them or lose them
        Rebate for points remaining
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: Use them or lose them Rebate for points remaining