Table of Contents | ||||
---|---|---|---|---|
|
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 |
|
|
|
|
...
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
Link
Operations
...
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 feature’s implementation status
Reference application and platform bug 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
...
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
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:
Note |
---|
We will need to sync between Product <> Engineering/Platform <> Program to finalize different types of reporting required for respective stakeholders. |