Product Team Ceremonies

Scaling Agile practices beyond a single delivery team means a collection of delivery teams will need to glean work from a product team.  Let’s just accept that as a fact and argue over the “agileness” of it later.  Given we have a product team with a Program Manager, Product Owner, BAs, Test Lead and Technical Architect, what are the ceremonies for that team?  If we look at the scrum ceremonies for delivery  teams are there similar ones for product teams?  Of course the answer is yes or this would be a very short blog post.

When we look at the work of the product team it falls into three categories, getting work ready, reporting on how the work is progressing and changing the process of the work.  This leads to five ceremonies for product teams, Release Planning, Feature Grooming, Roadmapping, Status Reporting and Retrospectives. So what is the purpose, timings and attendance for these ceremonies?

Release Planning

Release Planning can occur over several days prior to a formal release plan presentation to the portfolio or strategic level of the organization.  The purpose of release planning is to develop a viable plan to share with the rest of the business on what will be released to production.  Releases need coordination with marketing, training, operations and other business partners to ensure the software can be adopted by the intended audience.  With this in mind, releases are not software deployments. The key aspects of a release plan must contain the expected features, risks and timing of delivery. The product team generates the release plan with input from the delivery and portfolio or strategic teams.

Feature Grooming

Feature Grooming are sessions attended by the analysis and technical team members to marry the feature requirements to the technical solution.  These sessions can be held asynchronously but should include at least one review with the product owner to ensure that the stories broken out, and the solution presented, meet the intent of the feature.  Feature grooming is the time when the wants of the business are solved by the software being developed.  All high level stories for a feature should be described in sufficient detail that an estimate for the feature can be agreed upon.  The story map, technical details, visual tools, non-functional requirements and business rules should all be attached to the feature during these sessions.  Normally the product team meets twice a week to define and groom features for upcoming releases.

Roadmapping

Roadmapping sessions provide updates to the long term plan for the product with updates to the size and probable release date of features. Features that have not been groomed but have been identified are added to the roadmap.  As more details are known about the features, they are updated usually in color and shape on the map to communicate the likelihood that the feature will be delivered.  As priorities of the business shift, future features can be moved in the roadmap without impacting the delivery teams.  Roadmapping sessions are usually held once a week to share changes with the portfolio or strategic team and to respond to changes in the business.  Typically the Product Owner and Program Manager lead the roadmapping sessions.

Status Reporting

Status Reporting allows the product team to communicate the state of the current release, current roadmap and state of user adoption.  The Program Manager generally presents this session.  The format of this session is generally a weekly meeting for the product team and other stakeholders.  In addition, status may be reported at a formal portfolio or strategy team meeting and in preparation for release in a release readiness meeting.  All members of the product team should be able to communicate the status of the team, but it is the responsibility of the Program Manager to collect and distribute this information.

Retrospectives

Retrospectives are a key agile practice in which all product teams should participate.  Retrospective is the time for the team to look at what they are doing and how it is working.  It is the time where reflection leads to action items for changes in the process.  Retrospectives for the product team should occur near the time that the software is released and at a mid-point in the release cycle.  It should include only the product team members and they should be trying to focus on one or two items that they would like to change before the next retrospective.  This is not a lessons learned session as much as a forward looking change sessions.

Wrapping Up

With these five ceremonies agile product teams can clearly communicate to the rest of the business, respond to changes in business priorities, keep work read for the delivery teams and improve their own processes.