Before starting work on a ticket, ask yourself the following questions:
-
Who will benefit by the implementation of the ticket?
The end user? Other developers? Other systems? -
What do you need to edit in the code to implement the ticket?
Which classes or components need to be touched? -
How do you plan on implementing this ticket?
Which steps do you need to take? Break it down into small chunks! -
How long will each step take?
If you estimate a step will take more than 8 hours to complete, create a (sub) task or new ticket for it. -
The ticket estimate is the tally from all step estimates.
Round up if it does not total a number in your planning-poker card set.
The main benefit of this ticket will be for …
Because …
- Users can …
Any questions or uncertainties that arise whilst reading the ticket should be written here.
- Q. Can … be (re)used?
Does a new … need to be added? -> Should …
A. If different endpoint, create new lib.
- Add … in
/path/to/file/…
- Edit/Change … in
/path/to/file/…
(Any unexpected edits that take place during implementation should be added here)
- …
(Steps to take, some common tasks have been provided)
- Investigation (…h)
- Read … (…h)
- Create POC for … (…m)
-
Technical Design(None needed) - Implementation (…h…m)
- Completed task (…m)
- Uncompleted task (…h)
-
Cancelled task
- Verification (…h)
- …
- Final implementation round (…h)
- Minor tweaks / bugfixes based on review (…h)
- …
- Investigation (…h…m)
- Technical Design (…h)
- Implementation (…h)
- Verification (…m)
- Final implementation round (…h)
Total: …h (…h…m + …h + …m)
Based on somewhere between 6 (best case) and 3 (worst case) productive hours per diem, work will be completed between … and … work days.