Ticket Writing

Attendees

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