I think many times the role of product management within the Agile/SCRUM process can be somewhat vague, but mostly ends up being the product or business owner role (or both) in the process. Generally speaking, most product managers handle one product, but some are asked to handle many. I’ve outlined what I think is a straight forward way for product management to guide the Agile process across multiple products without becoming overbearing or involved beyond the bounds of sprint planning and burndown (happy efficient and empowered product development teams are the goal). I’ve chosen Jira as the project/issue tracking software here, but insert your organization’s choice during your read:
Let each team use Jira views and manage their scrum meetings as the SCRUM master sees fit and in a manner they are most comfortable with, but standardize on the following:
Quarterly goals = Epics
At the beginning of the quarter the Epics are broken down as much as reasonably possible into stories. Product management determines priority based on customer interaction and analysis. Engineering team determines how much can fit into each Sprint.
Each Sprint starts on the same Monday and ends on the same Friday. This will make for a full day of meetings for product and business owners, but gets it all done at once. Each should be scheduled for 2 hours to ensure time to complete discussions and empower the team to execute during the Sprint.
1. User Stories are entered into Jira by product management or business owners (Story Owner).
(Sprint Planning Meeting – 2 hours)
2. Product Management proposes stories for inclusion in Sprint during planning meeting.
3. Engineering team decides what they will commit to and adds sub-tasks to each story and assigns to engineers.
(Daily Scrums – 15 minutes)
4. Occur independent of product management and business owners. If questions arise for clarification from product management and business owners, team adds comments to Story during SCRUM (watchers get notification to answer).
5. The engineering team lead will set the state of the User Story to “resolved” once the sub-tasks are also resolved and closed (closed is the state after verification of a resolved sub-task).
(Story Review – 1 hour)
6. Product management and business owners review Backlogged stories with engineering leads. Any ambiguities are resolved and additional story splitting occurs if deemed necessary. This ensures efficiency at Sprint planning time.
(Sprint Burndown – 2 hours)
7. For each resolved story, Story Owner will verify the functionality (either through live demo at burn down meeting or independent review if applicable).
8. Story Owner sets User Story to “closed” or identifies why the User Story can not be closed, enters comments, and re-opens. Story placed back on the Backlog for reprioritization during Sprint planning.
(Sprint Review – .5 hours)
9. Team reviews what didn’t work for process and identifies how to change for next sprint.
1. Epics are the quarterly goals for each project
2. User Stories are added to each Epic by product management (before planning meeting)
– User Stories must consist of a templated description (I as a user …do thing…for goal…)
– User Stories may contain business value and estimates
– User Story summaries should be the artifact or unit of value upon completion
(e.g. Create documentation for module x, create functionality that allows y, document design for database schema)
– User Story DoD (definition of done) should be derived from description and summary and may or may not directly map to sub-tasks
3. Committed to Stories are broken down into sub-tasks and assigned to engineers (during planning meeting).
4. Sub-tasks are resolved by engineers and closed once verified (method up to SCRUM team).
5. Once all sub-tasks are closed, Story is resolved by engineering team.
6. Resolved stories are reviewed and closed or re-opened by story owner