Ticket Writing

@Nikodem Graczewski (Unlicensed)

@Wesley Brown

@Clay Crosby (Unlicensed)

@Antonate Maritim (Unlicensed)

@Jason Rogena (Unlicensed)

Others from ONA

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