Side Menu

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

Issue is a general term in software engineering. Issues are units of work to accomplish an improvement in a system. Issues could be requested features, bugs or writing documentation. In agile, there are some usual issue types that are depicted in the next Fig. 1 and detailed in the following.
Figure 1: Issue types

The diagram above denotes the typical terms in UML (Unified Modeling Language) Class diagram with Sprint and Release (set of delivered issues):
  • Initiative
  • Epic
  • Story
  • Improvement
  • Bug
  • Task

Beyond Initiatives: Goals and Objectives 

In many organizations the leadership team encourage the pursuit of some goals which directs each department.

In agile product development, a Goal (as an result-oriented endeavor) refers to an entire living system, not just a goal just for the Product Owner. For example, a Goal could be the development of a new system for the whole organization. 

On the other hand, an Objective defines the specific, measurable outcome (also an result-oriented endeavor) each team member must take to achieve the related goal. While Goals provide direction, Objectives measure how the team follows that direction.

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

As software developers, our job is to design and build initiatives - a.k.a. capabilities - that help the businesses realize their business goals. An initiative gives the customers the ability to achieve some goal or fulfil some task, regardless of the implementation. 

There are two categories of initiatives, business initiatives and enabler initiatives:
  • 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
Notes on How to write effective Initiatives
All initiatives should have the following information:
  • 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
A summary - as a template - could be found on Fig. 2:
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

Epics are the building block of the specifications. They should include all the implementation details of the features from the customer point of view. All Epics should be written down as specification pages - e.g. Confluence pages. Materializations of epics as Confluence pages result in the following benefits:
  • Direct relationship with JIRA issues
  • Ease the progress of the development (issue statuses are shown on the page)
The specification follows the best practices of BDD and agile best practices, namely:
  • 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

The way you write the Story would determine the outcome of the deliverable. It’s important to include the following 5 essential components in the form of specifications:
  1. User-centricity: Story must provide some form of value to a specific user/group
  2. 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
  3. 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
  4. 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)
  5. Clear acceptance criteria: at the end of the sprint, the solution will be evaluated against these criteria to ensure that the stakeholders are satisfied
Notes on How to write effective Story
Writing Stories in the Gherkin format (given, when, then) to be helpful since this accounts for pre-conditions - on Fig. 3:
Figure 3: Story template

Notes on happy and unhappy paths
Many people make the mistake of only testing happy paths, or what users are supposed to do when using an application, and neglect testing unhappy paths, or the many ways that users can break your software. By doing so, they may not be prepared to properly handle errors. We use this quick list as a reminder to consider the different types of paths which can be taken by the user:

CRUD actions:
  • Create
  • Read
  • Update
  • Delete

WEESLD states:
  • Waiting
  • Empty
  • Error ← THIS IS VERY IMPORTANT
  • Success
  • Limits
  • Default Values

Configuration options (FSSPI):
  • 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?)

Other things to consider:
  • 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

It is equivalent to Story formulation.

Bug

A problem that impairs product or service functionality that is expected (i.e. verification and validation). If something is not specified exactly, then that should entails either a new Story (missing complete function) or a new Improvement (amending a disposable function), in other cases only the system is corrected.

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

Bug tracking is one of the most critical stages in the software development lifecycle. They are expressed within a given Bug issue. In every process, the fundamentals of the effective defect tracking are the implementation of the following four extra attributes which fields should be filled to every defect reporting. 

Affected version and Fixed version
Both attributes relates to the Bug issue type only:
  • 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.
Bug's severity and priority
The two main parameters that form the basis for effective defect tracking and resolution are priority and severity. These are often a confusing concept and are almost used interchangeably amongst not only test teams but also development teams. There’s a fine line between the two and it’s important to understand that there are indeed differences between the two:
  • 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

No specific formulation of tasks due to their ramifying nature. Any textual description is adequate.

Notes on features vs. epics

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.

Notes on breaking down the work for planning
The breaking down the work helps the development team to better understand what they needs to be done. These detailed descriptions could be found within in each issue type and embodied as filled in templates in the following sections. The Fig. 1. depicts those issue types which are used in agile planning.

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)


ByPosted
Share
Labels, ,