Analytics/ProductManagerDutiesHandover
This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on any information on this page. |
Product Manager Duties edit
Our product manager has two complementary responsibilities. The first is to act as a Product Owner and Business Analyst and work with the development team to specify, design and ship software on a regular cadence that delights our customers.
The second is to work as a more conventional Product Manager, where in co-operation with the Director of Analytics, the Research and Data team lead and the Development team, help set the strategic direction for the work of the development team.
This is a lot of work and depending on the Product Owner responsibilities, it might be difficult to do the work associated with the Product Manager duties. The plan is to monitor this moving forward and have the Director assist here when necessary. An interesting comparison and commentary on PM versus PO responsibilities is here.
Additional Documentation edit
Our process is documented in this Google doc. It would be awesome to make it publicly available and/or convert it to a wiki. (It's a google doc for historical reasons) There are two other versions that we need to deprecate or delete: one and two
The document that the WMF uses as a reference for our scrum process is here. While I like this document, it should be considered aspirational -- we do not follow all or even most of its recommendations.
The mobile team has probably the best internal documentation. Again, we follow some but but not all of these principles.
Development Artifacts edit
We have a number of development artifacts that we use to manage our backlog and our sprints:
- Prioritization Hub where our current epics are listed along with links to requirements
- Planning Board (Mingle)
- 2014 Showcases
Status of Transitioning Activities edit
| Frequency | Activity | Artifact | Responsibility |
|---|---|---|---|
| Daily | Standup | Kevin | |
| Bug Triage | Bugzilla | Toby | |
| Weekly | Update to Public Lists (Friday) | Email Report | Toby |
| Tasking | User Stories / Etherpad / Estimates | Kevin | |
| Backlog Grooming | User Stories / Backlog | Kevin | |
| Staff Meeting (Tuesday) | |||
| Biweekly | Sprint Planning | User Stories, Dan's Spreadsheet, Mingle | Kevin |
| Showcase | Deck | Kevin / Dan | |
| Retrospective | Etherpad, Email | Kevin | |
| Monthly | Dev Updates (WMF) | Text Report | Toby |
Handover edit
Operational Handover (30-60 days) edit
Currently, the Director is performing the role of Product Owner. This has been generally sub-optimal and the development team has been doing a great job in executing and filling in the gaps. But this needs to end. This phase is focused on bringing the new PM up to speed with the team, how we work and all the idiosyncrasies of the Foundation and our stakeholders. Note that the team is a bit exhausted with discussion of process, so we should not try to implement any wholesale changes initially.
Goal: Product Owner responsibilities handled completely by the new PM.
Artifact: Documents updated to reflect how things really operate and shared publicly (let's replace old deck with wiki docs)
Specific Tasks:
- Start rewriting the user stories to make them more directed and smaller
- Editor Engagement Vital Signs
- Follow up with R&D (Aaron) on Metric definitions
- Decide on scoping for #1227 (The browser report for mobile)
- Editor Engagement Vital Signs
- Expand requirements for new high priority Epics
- MVP for EEVS
- Dashboard Discoverability/Annotations
- Update Mediawiki Epic page with new prioritization
- Bugzilla triage (should we push this off to phase 2?)
Optimization (60 - 120 days) edit
It is likely that after spending some time with the team and the process that some optimizations will be needed. A particular sore spot is the tooling. This phase should be focused on working with the Scrum Master and the development team to make any necessary changes to the process. Another interesting area of improvement might be a shared definition of Done.
Goal: Product Development process solidified in co-operation with Scrum Master and Development Team. if necessary, migration to new tooling. New process steps documented.
Artifact: Epics and backlog in new tool (if required) and new process steps documented.
Sustainable Development (120 days onward) edit
It is desirable that we get the process where it needs to be and limit our changes to small tweaks as needed.
Goal: Operational excellence -- we are able to release software at a sustainable pace that meets the needs of our stakeholders.
Artifact: Documentation updated regularly, understood by our stakeholders.
Projects edit
This is a unordered list of projects that might be taken on during the first few months
- Tool selection