Ticket Writing

Attendees

• Nikodem Graczewski (Unlicensed)
• Wesley Brown
• Clay Crosby (Unlicensed)
• Antonate Maritim (Unlicensed)
• Jason Rogena (Unlicensed)
• Others from ONA

Meeting Recording

Discussion Points

• Review of the overall ticket writing process

  • gathering functional requirements
    • meeting with Product Owner or someone from the VR side
    • confluence page
    • writing down user stories, unless they are already provided
  • brainstorm for creating stubs, discussion across the team
    • plan from a programming point of view, not users as the latter approach might require complete rework of the feature (shipment view)
    • gather questions
    • come up with a suggested solution (possible multiple solutions)
    • vaoid concurrent work on the same piece of code
    • best not blocking itself (if they do, add related tickets as blockers)
    • separate tickets for design
      • mockups
      • ramls for new endpoints
      • early feedback
    • separate tickets for implementing and using components/endpoints
    • ui / backend split
    • tickets for functional tests
    • consolidate list of edge cases (and finding solutions)
      • should be added to the ticket description
      • should be covered by tests
    • plan test cases
      
      • the feature should be cover by as little test cases as possible
      • no test case per ticket approach
  • get feedback from the VR side
    • most likely meeting for answering questions
  • add descriptions to the tickets
  • estimate
  • plan the work throughout Sprints
    • finish as much blockers as possible during the first Sprint
    • Stock based requisition as example (Proof of Delivery work plan)

• Ticket sizing

  • 1 sp
    
    • trivial change (1-3 lines of code edited)
    • requires the ticket to go through the whole workflow (Progress → Review → QA)
  • 2 sp
    • multiple lines of code edited
    • rather updating existing code rather than creating new one
    • ex. adding confirmation and notification to a button
  • 3 sp
    • adding simple new screen/modal
    • ex. adding Service Accounts page
  • 5 sp
    • adding complicated page (table, tabs, forms)
    • ex. adding User Roles page
  • 8 sp and above should ideally be split

  • Estimation reference tickets (in progress)

• Importance of splitting tickets when translating from user tickets to developer work

• good ticket
  • epic
    
    • depending on size should contain user story
    • overview of the feature
    • focused on user requirements
    • no technical details
    • should contain list of tasks
    • sizing - should be done in one release
    • reason tagging and stock reason epics as example
    • confluence page (and vice versa)
  • ticket
    
    • user story for feature tickets
    • story tickets should not contain technical details (that's for Task ticket)
    • mockups for UI tickets (especially design)
    • performance thresholds for endpoints
    • clear ACC
    • components and labels
    • fix version
    • story points
    • list of related tasks and blockers