Transcript of "ADM Overview - Customers"

3.
What is ADM? ADM is a modified Scrum/XP style of product development that is specific to Salesforce. It employs Scrum project management framework, adopts certain XP practices and is based on lean principles.

10.
Roles: Product Owner <ul><li>Single throat to choke </li></ul><ul><li>Fully accountable for the success or failure of the scrum team </li></ul><ul><li>Owns and prioritizes Product Backlog </li></ul>

13.
Roles: Scrum Team <ul><li>Cross-functional team </li></ul><ul><li>Has tasks on the Sprint Backlog </li></ul><ul><li>Self organizing, Self correcting. Teams decide best way to deliver </li></ul><ul><li>Makes their own commitment with the resources available, decides how best to distribute tasks to team members </li></ul><ul><li>Members are dedicated resources (as much as possible) </li></ul><ul><li>Optimally 6-10 people </li></ul>

16.
Release Planning <ul><li>Communicate a common vision for the release </li></ul><ul><li>Initial Design </li></ul><ul><li>Align team on proposed functionality </li></ul><ul><li>Determine target functionality for the release </li></ul>

18.
Sprint Planning <ul><li>Determine the Sprint Goal </li></ul><ul><li>Determine work necessary to complete the goal (with time estimates) </li></ul><ul><li>Make commitments for the Sprint </li></ul>

19.
Sprint Planning Meeting <ul><li>Team “dog piles” on user stories </li></ul><ul><li>Team figures out how to deliver Sprint Goal even without a resource on the team who normally does a particular type of work </li></ul><ul><li>Product Owner may negotiate but Team always determines what they can complete during the sprint </li></ul>

21.
<ul><li>The standards by which we define &quot;done&quot; for sprint functionality is key to the success of iterative, incremental development. Functionality that meets these standards at the end of a sprint will be considered potentially release-able and demoed at the Sprint Review. </li></ul>Definition of “Done”

22.
<ul><li>User Stories </li></ul><ul><li>All defined Acceptance Criteria for a user story have been met. </li></ul><ul><li>Code </li></ul><ul><li>Code implementing the user story functionality is checked in and follows department standards . </li></ul><ul><li>No open regressions (you break it, you own it), with automated tests written for all regressions. </li></ul><ul><li>No open P1 & P2 bugs for the implemented functionality in the sprint. </li></ul><ul><li>Quality </li></ul><ul><li>Code Coverage of 70% </li></ul><ul><li>Test plan, cases and execution for sprint functionality, regression and cross functional test cases related to sprint functionality, need to be 100% executed, and all P1/P2 cases passing. </li></ul><ul><li>All resolved bugs have been verified and closed for the sprint functionality. </li></ul>Definition of “Done”

25.
Sprint Review <ul><li>It’s all about feedback, visibility and course correction </li></ul><ul><li>All teams demo done functionality to All Technology / Stakeholders </li></ul><ul><li>Takes place after the last day of the Sprint </li></ul>

27.
<ul><li>Looks at “how” team operates and product is built (process, tools, etc.) </li></ul><ul><li>Occurs after every Sprint </li></ul><ul><li>What went well? </li></ul><ul><li>What didn’t go well? </li></ul><ul><li>What will you do differently next time? </li></ul>Retrospective