I’m always impressed by Product Managers who seem to have their work life under control: well-planned calendars, neat to-do lists and what not. (Kudos to Catherine Shyu from Sendgrid, Ellen Chisa from Kickstarter and Max from Globehop – who happens to be the guy who introduced me to the world of Product Management)
In contrast, my notebooks and to-do lists kinda look like Godzilla was trying to paint with a teeny paintbrush (it ain’t pretty). Principle-based living seems to work better for me. Still, I try.
Today I was inspired by this introduction to Scrum and this article on triaging Backlog items to come up with a more structured workflow. And – gasp– I even put some recurring events in my calendar for some of them:
- Personal Triage Session (2 hours): running through Raw Feedback to determine whether to (1) transfer it to the Product Backlog as a story or an epic, or (2) send it to the “graveyard”
- Personal Backlog Review (2 hours): running through the Product Backlog to pick out topics for refinement and for initial prioritization – I will shortlist some items for the next sprint, and then another 20 or so items. Sufficiently refined topics will transition to a different status (we use” Selected for Development”), while the rest remain backlogged. I’ll probably need my Product Strategy ready so this prioritization is more effective.
- Team Backlog Prioritization Meeting (2 hours every 2 weeks): Running through stories without clear implementation solutions, to get team input. Estimation of stories and other backlog items. Further prioritization of next sprint and top 20 items.
- Team Planning Meeting (1 hour every 2 weeks): Firming up items for the sprint/release and clarifying specs further.
- Retrospective (1-2 hours every 2 weeks): review the release mostly from a process standpoint – the blockers, the good, the improves.
Purists might point out the differences between true Scrum and this workflow, but I think this is a good start, maybe a bridge to adopting more proper practices (or jettisoning them away if not working).
One of the concerns I do have with Scrum is managing the roadmap – how do you put a date on stories that aren’t estimated or defined, especially when you estimate them only once a sprint? Maybe it’ll be like what the video – if you can’t apply proper Scrum, it probably has more to do with the organization than the practice itself.