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