How to Create Tickets and Cards

This may also be best learned during a project (on a project-by-project basis)

Epic

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

User Story

  • 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 don't 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.

Implementation Plan

  • Notes that explain how/where to start
  • Helps if another engineer has to pick up your ticket

Acceptance Tests

  • 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

QA Tests

  • 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

Estimates

  • 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