Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Sniper team 101


Published on

  • Be the first to comment

  • Be the first to like this

Sniper team 101

  1. 1. Sniper Team 101
  2. 2. Sniper Team Composition• 1 – 7 developers (currently 5)• 0.25 designers (floating resource from the design team)• 1 QA as of February
  3. 3. Sniper Team Formation• Created about 3 years ago with the brief to fix small bugs, add small features and investigate and fix customer problems• Increasingly involved in intern, graduate and junior developer training• All around fix it team for problems in the development process
  4. 4. • Floating resource for projects that require additional help
  5. 5. Sniper Team Process• The sniper team work falls into two main categories: tickets and issues – Tickets: requests from CC/Billing/Bank Feeds/ Enablement to investigate and resolve problems that customer and partners are experiencing with the Xero system – Issue: Requests for changes or enchantments to the Xero system. This can result from a ticket, customer request, product managers, design, QA...
  6. 6. Issue workflow
  7. 7. Features or Functional Changes• Trello: used as a collection point for requests for changes to the Xero system.
  8. 8. • Prioritisation meetings with mayor stakeholders to determine which changes will be included in the upcoming release• Issues created in Boss and assigned to the upcoming release• Development work completed by Sniper Team• Tested by QA• Release to live
  9. 9. Bug Fixes• Issues created in Boss by QA and assigned to the Sniper Team for an upcoming release• Development work completed by Sniper Team• Tested by QA• Release to live
  10. 10. Ticket Workflow (From the sniper team perspective)• The tickets status is changed to “In Sniper”. This is the first point at which we’ll see the ticket• The ticket is assigned to a developer and the investigation begins
  11. 11. Investigation• Login into the organisation via the CC user on live and attempt to reproduce the problem• Look in Splunk to try and find the error.
  12. 12. • Check the organisation on livestage if possible• Check the code to see if it’s a systematic problem
  13. 13. Problem Source• Bad data in the database• A bug in the code that is triggered by a particular situation• A combination of the two.
  14. 14. Fixing Tickets• Bad data: Fix the data in the database (some of the sniper team have access to the production database), then try and determine how the data got there• Bug: Raise an issue in Boss. The number of customers affected and the severity of the problem will determine what release the fix will go into
  15. 15. Common Ticket Examples• Ghost Payment ( (• Statement lines not showing as reconciled when they are ( )• Statement lines reconciled to deleted payments ( 85ec-4cdb-b32c-f8a967c8dca6)
  16. 16. • Bank reconciliation report showing statement lines that are reconciled as un-reconciled. ( 4ab9cd3aa8ca&statementLineID=5f9b3a82-9618-44e2-8e8c-b7b57d9d7553)• Approved invoices that have no journals (• Report/Page timeouts
  17. 17. • Reactivating deleted bank accounts that have bank feeds• Deprecation that can be rolled back• Deleting user accounts• Reactivating deleted trial organisations