How to Create Tickets and Cards
This may also be best learned during a project (on a project-by-project basis)
Description: An epic often starts as the big picture and then the user stories fill in the details. But it is also possible that a group of user stories (as they are prioritized) coalesce into an epic.
Who Creates Tickets/Cards
- Product Owners
- Project Managers
- UX Team
- As a(n) X I want to Y so that Z (outcome)
- Describes the user need for the work to be done
- As an anonymous user, I want to see the latest news articles on the homepage so that I do not have to view older articles that I may have already read.
- Avoid more than one action per user story. Red flags would be commas and "ands" - Consider splitting into multiple tickets.
- Notes that explain how/where to start
- Helps if another engineer has to pick up your ticket
User Acceptance Tests (UAT)
- Explains how we validate that this card works
- Written in a language anyone can understand
- Explains what the ticket will not do as well
- Acceptance Testing is the process that verifies if the installed piece of code or software works as designed for the user
- Ideally the Product Owner (PO) writes the Acceptance Test for a piece of work
- Testing with users is an important factor in ensuring the work is performing/created as expected
- Written step-by-step so that anyone can pass/fail the test
- The PO will also run through the same test
- It will also explain the expected results
- Specific directions/steps a tester can follow that ensure what was developed produces what the engineer intended
- Every ticket must be estimable
- Estimate tickets at the beginning of a sprint
- Co-working encouraged!
- Track your time daily
- Estimates should consider time for QA (on average +20%)
- Projects use story points for estimating