Practical agile issue types
The Institute of Electrical and Electronics Engineers defines the term feature in IEEE 829 as "A distinguishing characteristic of a software item (e.g., performance, portability, or functionality)". More practically, features are what we build, and they are that delivers value for the customers. They could also be considered as the functional elements of the deliverable systems.
However, in practice, the development workflow requires a finer-grained work item categorization. Therefore, agile development work items should be broken down categorized into different lower-level issue types. In the following, a proven, up-to-the point definitions and selection of issues could be found.Issue types
- Initiative
- Epic
- Story
- Improvement
- Bug
- Task
Initiative
Initiatives are collections of Epics that drive toward a common goal. An initiative contains many Epics and its delivery lasts typically a couple of months.
Initiatives' end dates are shown on roadmaps as milestones.
Examples
- Fully functional initial system (Emerald 1.0)
- Revamped user interface (Emerald 1.1)
Formulation
- Business initiatives – directly benefit the business or its customers.
- Enabler initiatives – does not directly benefit the customer but completes work necessary so that one or more business capabilities can subsequently be implemented
- Phrase – a brief description of the capability
- Benefits hypothesis – a statement, which can be validated, they are about the benefits of the capability
- Business goal relationship – denoting its reference to the relevant business goal
Figure 2: Initiative template |
Epic
An Epic is a large piece of work that encompasses many issues. An Epic can be considered as a large Story that cannot be delivered as defined within a single iteration or is large enough that it can be split into smaller Stories.
Epics are shown on roadmaps as lanes.
Examples
- Editing and viewing user data in a consolidated view
- Searching documents in the system
- Authorized user could access the system
Formulation
- Direct relationship with JIRA issues
- Ease the progress of the development (issue statuses are shown on the page)
- Breaking down the requirements as Stories
- Formulating specifications using a simple domain-specific language (i.e. IF...THEN...)
- Explicitly mentioning the relevant users and the provided business values
- Determining the UIF mockups and related elements (colors, UIF elements, icons, etc.)
- Language translations
- Defining the acceptance criteria for the development
- Helping formulating Test scenarios for the Testers
Story (a.k.a. User story)
Story is a functionality request expressed from the perspective of the user. Stories are the smallest units of user functionality. A Story must deliver particular value to the user and must be described in simple language that outlines the desired outcome. A Story is essentially a user requirement that’s focused on the user’s experience.
Stories are shown on Kanban boards as cards.
Examples
- (continuing Authorized user could access the system) Sign Up with Email
- (continuing Authorized user could access the system) Log In with Email
- Searching within defined time interval (subset of documents)
Formulation
- User-centricity: Story must provide some form of value to a specific user/group
- Background and context: brief background and context can help team members to understand the rationale of the requirement, which allows them to exercise discretionary decision making in times of uncertainty
- Screen flows: the sketches and mock screens the best way to align requirements among the various stakeholders from business users, designers, architects, and engineers — to ensure that everyone is on the same page and looking at the same picture
- Technical specifications: technical diagrams and specifications provide team members with clarity on the deliverables (e.g. color codes, button states and behaviors, tooltips, labels, error messages, other language translations)
- Clear acceptance criteria: at the end of the sprint, the solution will be evaluated against these criteria to ensure that the stakeholders are satisfied
Figure 3: Story template |
- Create
- Read
- Update
- Delete
- Waiting
- Empty
- Error ← THIS IS VERY IMPORTANT
- Success
- Limits
- Default Values
- Filtering (single parameter, multiple parameter)
- Sorting (single parameter, multiple parameter)
- Searching (single term, multiple term)
- Pagination (page size, page number)
- Include (what related information can also be returned in the response?)
- Data formats, lengths (e.g. Strings, Date YYYY/MM/DD)
- Language support (e.g. HUN+ENG (default), or Hungarian only)
- Colors of the control elements
- Widgets (input forms, validation rules)
- Loading spinner
- User messages (around widget, modal dialogue, toast - see below)
- Case sensitivity (e.g. in search)
- Encoding (default: UTF-8)
Improvement
Enhancement of an existing Story.
Examples
- (continuing Log in with email) Validation of email address
- (continuing Searching within defined time interval) Validation of time interval
Formulation
Bug
Examples
- (continuing Validation of email address) Top level domain name are not checked
- (continuing Searching within defined time interval) Time interval could be a future date
Formulation
- Affected version: is the version in which a bug or problem was found. (This element should be filled with the related Affects Environment field.)
- Fixed version: is the version where you plan on releasing a feature or bugfix to customers.
- Defect priority: the priority of a defect would indicate the urgency with which it would need to be fixed
- Defect severity: the severity of a bug would indicate the effect it has on the system in terms of its impact (e.g. Blocker, Critical, Major, Minor)
Task
A Task is that it needs to be done but not related to the product functionality (i.e. Stories). Tasks are decomposed parts of an Epic that get into HOW the Epic will be completed in term of non-developer or not-specific Epic-related endeavor. (Stories are the same level as Tasks.) Tasks can be hour estimated if desired. Tasks are usually defined by the people doing the work (developers, QA, etc.).
Examples
- Composing deployment script
- Modelling a specific regulation (e.g. KATA) with the tool
- Refining the logging system of the application
Formulation
Both Features and Epics are breakdown elements of Initiatives, although their intents are different. Features are system functionalities (described in technical or company's point of view), while Epics are user centered functionalities (business point of view). So they are the two sides of the same coin.
For example, an Epic could be " Searching documents in the system" or "Editing and viewing user data in a consolidated view " (user's perspective) the related Features could be "Document Search Service" or "User profile management" (system's perspective). It is important to note that there is a many-to-many relationship type between them.
Usually, many Features comprise Components (closely-related functionality in a system), and Components comprise the whole System.
Figure 4: Issue types for planning |
Subtasks in Jira
Subtask is designed in Jira as an issue tracking-related issue type. It means that it could not be used for planning but for check-lists. Therefore, the practical applicability for planning is strongly constrained - although there is a long heated debate on the Jira blogs... - due to the followings:
- Only parent may have estimation
- Subtask assignee work could not be tracked (difficult to estimate individual work)
- Subtask lives as long as their parents live (i.e. if some subtasks are not completed in a sprint an other parent issue could be created and those subtasks should be re-assigned)