User Tools
Writing /app/www/public/data/meta/development/jiras.meta failed
development:jiras
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| development:jiras [2016/08/12 18:16] – jrellis | development:jiras [2021/06/25 10:09] (current) – external edit 127.0.0.1 | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | ====== Development JIRA Guidelines ====== | ||
| + | |||
| + | Author: John Rellis | ||
| + | |||
| + | ---- | ||
| + | |||
| + | [[https:// | ||
| + | |||
| + | [[https:// | ||
| + | |||
| + | |||
| + | ===== Stories are singular in purpose ===== | ||
| + | |||
| + | A nocuser should be able to see venues in the nocportal and also view venue reports | ||
| + | * This is bad! This should be two jiras, one for noc portal and one for specific report changes | ||
| + | |||
| + | ---- | ||
| + | |||
| + | ===== JIRA Description Rules ===== | ||
| + | |||
| + | ==== Rules ==== | ||
| + | |||
| + | * All requirements should be in the JIRA description, | ||
| + | * The description should further explain the title of the story. | ||
| + | * Storypoint or LOE estimate should not be added by the support team unless discussed with a developer and agreed upon - leave 0 otherwise | ||
| + | |||
| + | ==== Sections ==== | ||
| + | |||
| + | The JIRA Description should contain the following subsections | ||
| + | |||
| + | * Feature/Bug Summary - This should elaborate on the user story or bug title and describe the problems it is solving | ||
| + | * Steps to Reproduce Issue - Typically only relevant for bugs | ||
| + | * Background Information - Information on the history of the item | ||
| + | * Related Tickets - For example " | ||
| + | * Proposed Solutions - Any information that should be considered as part of the solution including pointers, warnings etc | ||
| + | * Potential Additional Tasks - Any tasks, like database loading, that might need to be considered in the LOE, this can remain here during grooming | ||
| + | * These tasks should become subtasks to be deemed sprint ready, they should be noted here once grooming is complete | ||
| + | * Unresolved Questions - All of the questions that must be answered before considering the item sprint ready | ||
| + | * Note, all unresolved questions should be < | ||
| + | * < | ||
| + | * This information is then required to be added to the proposed solution or new subtasks if necessary | ||
| + | |||
| + | Paste this into your JIRA description before beginning | ||
| + | |||
| + | < | ||
| + | {panel: | ||
| + | {panel} | ||
| + | |||
| + | {panel: | ||
| + | {panel} | ||
| + | |||
| + | {panel: | ||
| + | {panel} | ||
| + | |||
| + | {panel: | ||
| + | {panel} | ||
| + | |||
| + | {panel: | ||
| + | {panel} | ||
| + | |||
| + | {panel: | ||
| + | {panel} | ||
| + | |||
| + | {panel: | ||
| + | {panel} | ||
| + | </ | ||
| + | |||
| + | ---- | ||
| + | |||
| + | ===== Comment Rules ===== | ||
| + | |||
| + | * Comments should only be used by the implementing developer to track progress so that if they need to leave the item, someone can pick up where they left off. This will also serve as a progress marker to the Scrum master | ||
| + | * Comments should not be used to add requirements, | ||
| + | * If you absolutely have to store sensitive information in a restricted comment, there may be one comment entitled, " | ||
| + | |||
| + | ---- | ||
| + | |||
| + | ===== Sprint Ready ===== | ||
| + | |||
| + | During backlog grooming, the following labels should be used on each JIRA until they reach Sprint Ready in the Sprint Planning meeting | ||
| + | |||
| + | * CUSTOMER_CLARIFICATION_REQUIRED | ||
| + | * INTERNAL_R& | ||
| + | * SPRINT_READY | ||
| + | * All unresolved questions have to be resolved before this label can be applied. | ||
| + | * All additional tasks need to be quantified and made subtasks, see the note on Potential Additional Tasks above. | ||
| + | |||
| + | |||