Versions Compared

Old Version 9

changes.mady.by.user Hena Shah

Saved on

compared with

New Version Current

changes.mady.by.user Hena Shah

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents
minLevel1
maxLevel7

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.

...

Info

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

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)

...

  • 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

...

TBD based on updated Done process

Implementation

TBD

We can set up various workflows depending on the type of work. But for now, this should suffice.

Note

To run multiple sprints and standardize issue information, in RAIN project needs to be migrated to the next-gen JIRA. → Need support here.

(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:

Note

We will need to sync between Product <> Engineering/Platform <> Program to finalize different types of reporting required for respective stakeholders.