/
Ticket Writing

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
  • 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


Related content

Code Review Checklist
Code Review Checklist
Read with this
Sprint 14
Sprint 14
More like this
Translations
Translations
Read with this
SolDevelo Onsite Meeting - Seattle Aug 2016
SolDevelo Onsite Meeting - Seattle Aug 2016
More like this
Docker Cheat Sheet
Docker Cheat Sheet
Read with this
Sprint 9 Goals
Sprint 9 Goals
More like this

OpenLMIS: the global initiative for powerful LMIS software