,
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. The second row be). 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 |
|---|---|---|---|---|
Components |
|
|
|
|
Standardization
Epics, Stories, Tasks, Bugs
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 |
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
Release feature’s implementation status
Reference application and platform related bugs reported during implementation
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
We can set up various workflows depending on the type of work. But for now, this should suffice.
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
Readiness for a sprint (Product and Engineering): To understand what is the type of work we’re prioritizing sprint-by-sprint
Product Sprint
Research, Design, Development related
GTM & Partnerships related
Miscellaneous
Engineering Sprint
New features
Enhancements
Existing backlog and bug fixes
Sprint spillovers (Product, Engineering/Core, QA)
Bug Reports
Timelines
Implementation/Adoption of Changes
Some Work-In-Progress Sample Reports:
We will need to sync between Product <> Engineering/Platform <> Program to finalize different types of reporting required for respective stakeholders.