Open and Agile - JIRA Setup v1

Owned by Hena Shah
Last updated: Oct 10, 2021
3 min read

Objective

Going from 1 Mission to 4, our work needs restructuring to manage priorities, capacity, timelines, and quality better. With this document, we attempt to put forth a view of organizing the work using JIRA.

Mission Projects

Each Mission becomes a JIRA project, one mission one backlog, with standardized components (Components in JIRA are used to filter the work in the backlog). This will also include non-engineering work that a Mission undertakes.

To start with, we will add non-engineering mission work that the product team is undertaking/participating in.

Project

Core

Urban

Sanitation

iFix

Project

Core

Urban

Sanitation

iFix

Components

  • Analytics Revamp

  • Performance Benchmarking

  • GIS

  • Design System

  • Privacy

  • Testing Strategy

  • Documentation (core.digit.org )

  • Single Instance

  • PT

  • PGR

  • TL

  • OBPAS

  • Fire NOC

  • W&S

  • Documentation (urban.digit.org)

  • National Dashboard

  • FSM

  • SWM

  • Documentation (dishha.digit.org)

  • mGramSeva

  • iFix Adaptor

  • iFix Core

  • Documentation (ifix.digit.org)

Standardization

Epics, Stories, Tasks, Bugs

Item

Description

Item

Description

Epic

A large body of work taking more than smaller task to finish. These will include engineering as well as non-engineering large items that we undertake for a Mission.

Stories/ Task

Smaller tasks/requests/requirements/testing/etc required to complete an Epic

Reference

We’re keeping this estimation framework while adding Epics/Stories

  • Small (S): 1-2 weeks

    • Doable within one product (and/or one engineering sprint) 1-2 weeks

  • Medium (M): 2-3 weeks

  • Large (L): 1 month

Open Question: How do we want to roll up Epics to an Initiative level?

Issue Information

Every issue ticket (Epic/Story/Task/Sub-Task/Bug) will have the following details so that we can understand what our work is mapping towards:

Mission

  • Core

  • Urban

  • Sanitation

  • PFM

Theme

  • Access

  • Citizen Adoption

  • Enablement

  • Privacy and Security

  • Quality

  • Performance

  • Innovation

  • User Experience

  • Pilot and Roll Out

  • Completeness

  • None

Type of Work

  • Research

  • Design

  • Development

  • Enablement

  • GTM and Partnerships

Programs

  • CDG

  • Punjab

  • eChhawani

  • Uttarakhand

  • Odisha

  • None

Issue Description

  • Background

  • Solution

  • Scope

  • Actors

  • Details and Validations

  • Design Links

  • Notifications

  • Acceptance Criteria

    • Functional

    • Non-Functional

  • Metrics to Track

  • Stakeholders

    • Note: We will tag account managers, implementation SPOC, Engineering team, and other required stakeholders so that we are all on the same page about the design and status of a particular feature.

Links in the Issue

  • Test Cases

  • Related Bugs

  • Performance Report (if applicable)

Operations

 

An observation from our real-world scenario:

This is a very interesting Twitter thread. I would highly recommend going over it.

 

One of the proposed solutions is empowering the sprint teams to work together, which I believe is truly applicable in our context. So running Mission wise operations between Product <> Engineering/Platform <> Programs:

TBD Program/Implementation Process:

Looking to capture required Implementation related information in JIRA

  1. Release feature’s implementation status

  2. Reference application and platform related bugs reported during implementation

  3. Feedback

TBD is based on the final agreement with all program managers. Since we want to look at being more open, consideration for the above points

 

Issue Workflow

Product/Design

Engineering

TBD based on updated Done process

 

(WIP) Reporting

We will the Dashboards feature of Jira and set up reports for stakeholders. Key considerations we want to keep in mind for reporting

  1. Readiness for a sprint (Product and Engineering): To understand what is the type of work we’re prioritizing sprint-by-sprint

    1. Product Sprint

      1. Research, Design, Development related

      2. GTM & Partnerships related

      3. Miscellaneous

    2. Engineering Sprint

      1. New features

      2. Enhancements

      3. Existing backlog and bug fixes

  2. Sprint spillovers (Product, Engineering/Core, QA)

  3. Bug Reports

  4. Timelines

  5. Implementation/Adoption of Changes

 

Some Work-In-Progress Sample Reports: