Sprints for product management teams

Many folks have participated in typical agile processes with their development teams. Those sprints made developers go fast and also deliver meaningful chunks of work. What if product managers could do the same?

Photo by Steven Lelham on Unsplash

I wondered what could happen if a product management team used sprints to track their own workload. So no developers, no code repos, and no build breaks. Instead, my team of product managers embraced agile methods to drive their own product management productivity.

Our objectives:

• Transparency across the product management team
• Higher velocity in delivering our individual and team projects
• Improved cross-team collaboration (Marketing, Design, Sales, Dev…)

And our methods are simple but powerful:

• Two weeks for each sprint
• “Kanban” board in Trello for cross-team visibility and individual accountability
• Rituals: Planning Sessions, Slack scrum, Playbacks, and Retros

How it works

Our primary mode is the 2-week sprint that’s tracked in Trello. Just like any sprint, the tasks should be meaningful chunks of work that stand on their own and represent real value to our clients and to our company. Sounds hard to define, right? Not really. We quickly decomposed bigger efforts into smaller tasks.

Agile methods help to support those sprints. Backlog grooming is offline and at least monthly plus ad hoc updates. Sprint planning occurs in a meeting at the beginning of every sprint with NO planning poker. You might wonder why no poker. Most of the tasks are independently completed and didn’t require consensus among the sprinters. A weekly standup in a dedicated slack channel ensures light-weight communications with the rubric of DOING, DONE, BLOCKERS. The team feels that live scrum sessions aren’t helpful. And yes, playbacks were at the end of each sprint. Retrospectives cover two sprints (every 4 weeks) because we didn’t have enough content to make it more often.

Everything’s an experiment, so iterative changes to our process will occur as we adapt agile to product management. After two months of sprints, we reevaluated whether the whole concept was working. It was!

Playbacks. In the world of product management, it’s easy to talk about the work and to go to meetings about the work, but never really show the work. Our mantra is show not tell. Thus each person must share their screen and show that sprint’s completed tasks. It took a few reminders, but each member is now conditioned to share their screen and pull up their artifacts. Those playbacks are recorded for later reference, such as end-of-quarter reviews. So what’s being shown? Here’s a short list:

• New dashboards and new metrics
• Try experiences, such as demos, interactive walkthrough’s, and sign up forms
• Wireframes for marketing content
• Lead pass journeys
• Content plans
• Roadmaps

Tools

• Trello for sprints, shared across all team
• Department folder for artifacts and assets, stored in Box
• Meetings for collaboration: scheduled by myself and Scrum Master
• Agile manifesto as a historical reminder of the why and how: https://www.agilealliance.org/agile101/the-agile-manifesto/

A work management system, like Trello or ZenHub, is absolutely necessary. Our swim lanes took some time to solidify: backlog, current sprint backlog, in progress, verify/review, and done. The “current sprint backlog” items are identified by the team during the sprint planning session. Since our sprints are two weeks, some items sit there for a few days before being moved to the “in progress” lane.

Roles — shared responsibility

While it might seem like the Scrum Master should bear the burden of doing everything, in our team we spread the load across different team members. Here’s how we split up the work:

• First up is our Scrum Master. This person drives most of the rituals and follow-up’s that come out of those rituals. They also push individuals outside of scheduled rituals to ensure transparency continues, such as posting scrum status in slack, and to ensure sprint hygiene. Sprint hygiene includes things like cards having clear owners on the board, and that the board is tidy for sprint planning sessions.
• Slack channels: someone to set up and maintain our channels. This person also will nudge others if they’re not using those channels, such as sending emails or scheduling unnecessary “status meetings.”
• Retros need an invite owner and shepherd. I also included an 8-week mark to evaluate our retro methodology. Currently I as the manager hold this role.
• A Trello board (or whatever Kanban or work management tool) needs an admin. That board also should have swim lanes, labels/tags, power-up’s, and even nice visual imagery. The Trello board owner should have a backup, typically the Scrum Master.
• Last but not least is the Playback owner. Our scrum master and myself share this role.

What we’ve learned

Our retros and sprint planning sessions helped us to improve as we went along. For example, our Trello hygiene improved over time as folks ensured that they assigned themselves as owner (so they could filter the board). We didn’t get too worried about setting deadlines in the cards because our swim lanes drove velocity. Those retros also let the team share insights about better collaboration with stakeholders and to do quick ideation sessions (some spun out into separate meetings).

Another theme that came up was that sprinting doesn’t have to be boring. Our board became more colorful and included compelling imagery to reflect each swim lane’s goal. We even had background music during sprint planning sessions.

As I was tallying up the outcomes, I immediately saw our vibrancy with Trello labels to see where the hot spots are. Its dashboard showed me this handy (and sanitized view):

Similarly, I could see who’s overloaded or under-weighted:

Outcomes

It’s been an amazing five months since we started sprinting. We’ve learned and honed along the way. I’m most proud of:

• 109 unique product management tasks completed thus far.
• A healthy but growing backlog of 20 cards. Our backlog fluctuates given the time of year. I expect it will grow as we set our 2024 plans into motion!
• 11 playback sessions that are the evidence of all the daily grind of product management life.
• 5 retrospectives helped us build trust as a team and improve our practices.

Most gratifying is what I hear from the team:

“Sprints help me a lot with task prioritization and keep a mental “happy path” along with a collaborative spirit.” — Yash Joshi

“They (sprints) allow me to give more reliable deadlines to stakeholders and when something urgent arises, it means I am conscious of what will need to push out from my original plan, enabling me to mitigate any consequences to others.” — Andy Breeds

“Sprints also streamlined collaboration with my team giving me a much better view of everything that is happening and better aligns my tasks with theirs in order to work towards our common goals.” — Zeeshan Bari

“Sprints have been a great touchpoint to help re-calibrate around overarching priorities and focus on tangible deliverables every 2 weeks.” — Mark Heaton

What’s next

As I mentioned earlier, everything’s an experiment, so we’re evolving too.

• A more robust tool to replace Trello: Monday.com
• Epics to organize the smaller 2-week deliverables

So what do you think? Do you think your product management team could start sprinting too?