From Idea to Jira Issue

Objective:

In order to build flexibility and agility into our product process it is important to define a common practice of how an idea goes from conception to a piece of work the development team is going to execute on. This allows the product team to properly prioritize ideas and refine them just in time for the development time to execute on.

Issue Types:

Issues fall into three general buckets: stories, bugs, and tasks. Each type of issue has slightly different criteria as it moves through the four stages of refinement. An issue as defined here refers specifically to a Jira issue. Almost everything in Jira is an issue. Stories, bugs, and tasks are types of issues. There are also higher level issue types called Epics, and lower level issues called sub tasks. We will only be discussing stories, bugs, and tasks.

Story:

A story is an issue type in Jira that corresponds to a piece of work that can be completed within one sprint. All story’s should follow the INVEST model which means it is:

• “I” ndependent (of all others)
• “N” egotiable (not a specific contract for features)
• “V” aluable
• “E” stimable (to a good approximation)
• “S” mall (so as to fit within an iteration)
• “T” estable (in principle, even if there isn’t a test for it yet)

INVEST - Soure

Bug:

A bug is defined as when the system is not doing something in which it was designed to do. It’s important to differentiate between a bug and feature request pretending to be a bug. Bugs should always include steps to reproduce the issue and a description of what the expected outcome should be.

Task:

A task is anything that isn’t a story or bug, that will take substantial time during a sprint. Tasks do not need to subscribe to the INVEST model. Examples of tasks might include researching/evaluating different development methods, creating a build, or refactoring a specific piece of code.

Stages of Refinement

The stages of refinement refer to the four levels of definition an issue can exist in. New issues always start in Backlog where they can be roughly prioritized against each other and product can determine if they are going to be executed on in the next 1-5 sprints. Refinement defines the period when an issue is getting additional details added to the issue, this includes discussions with development and design teams as needed. The Grooming phase is the period when the development team reviews the goal and estimates effort. When a story is Ready it is ready to be added to a sprint for the development team to action. Below describes in more detail what an issue looks like in each step.

Backlog

New issues always begin in Backlog, where they are reviewed and determined if it will be actioned in the next 1-5 sprints Stories at this stage are required to have a descriptive title only All new issues should roll up to an Epic which groups similar issues together Issues should be roughly prioritized against each other, the higher in the list the more important/value the story will add. Bugs during this stage have steps to reproduce and expected result Tasks should have a single line that outlines the goal or problem

Refinement

• A story that has been selected for development moves into refinement
• Stories are updated to include a clear business goal, formatted as a user story
• Stories begin to be socialized with smaller groups of developers to determine feasibility
• Bugs should be quickly reviewed and an approach to address the issue should be discussed

• Tasks should have a clear goal for what will be achieved when complete

  Grooming

• Acceptance criteria has been added to the story
• Development team understands the business goal and has a rough idea of how they are going to execute
• Development team has enough understanding to add an estimation
• Issues are reviewed and estimated during a grooming session
• Bugs should be understood enough to have a clear plan of how they will be addressed

• Tasks should have acceptance criteria is added

  Ready

• The issue is ready to be prioritized and added to an upcoming sprint
• The issue has been estimated
• The development team has a clear understanding of the goal of the issue
• The development team has a general idea of how they will execute on the idea

Meetings

Three Amigos Meetings

• Discuss an early idea.
• Adhoc, and as needed.
• 1-2 developers and product.

Grooming Meetings

• Review all ideas in detail.
• Add estimates and dependancies.
• Full team.

Planning Meetings

• Prioritize stories.
• Discuss possible implementation approach.
• Commit to work to be done during sprint.
• Full team

What A Story Looks Like

Business Case:

As a [User Personal] I want [addition or modification to the system] so that [reason the user wants this to happen]

Acceptance Criteria:

I know this is done when…

• [Testable acceptance criteria]
• [Testable acceptance criteria]
• [Testable acceptance criteria]
• [Testable acceptance criteria]

Example

As an end user of the SDK I want to be able to clearly see the different tags my photo is returning so that I know that the system is starting to recognize the image that I tapped on.

I know this is done when…

• I tap on the an area in the camera a visual indicator is shown that will track to the item that was tapped
• When a tag is returned, the tags will be displayed one at a time tracking with the visual indicator
• The text tag is legible on any background (include black semi transparent background under white text)
• The text tags visually fade/animate in and out