#PCampBoston: Dev Backlog vs PM Backlog vs Roadmap

Early morning on a Saturday. Light breakfast. Networking. Opening session.

9:30am. People spread out into 14 different room in the Microsoft NERD center for the topic of their choice. Breakout session started.

9:35am. The facilitator who proposed this topic couldn't make it to the event.

9:38am. Before people stood up to leave, Phil Gross from Visual IQ stepped in: "Let's discuss this topic ourselves. It's a volunteer run event after all!"

The room soon turned into a lively discussion. People agree or disagree with each other, outspoken or thoughtful with words, all offered opinions and arguments. I'm especially proud for the collaborative effort we made in the short 40 minutes, that not just the loudest was heard, but the soft-spoken ones too joined. I felt a blast at the first session - as a first time participant at Product Camp, I saw the beauty of the peer-led "unconference".

Coming back to the topic. We're now all very familiar with the concept of a backlog. In my arrogant opinion, the backlog in our own basement was pretty much a dumpster for a long time. Whenever a user or business stakeholder came over to ask for a feature, or whenever some system defects surfaced, we jotted it down and threw it in the backlog. The developers, whenever got some extra time in the sprint, would go to the backlog and pickup whatever to fix.

This wasn't too big of a problem in a startup environment. When the team was small, the scale of problem we want to solve was small, and when everyone was wearing multiple hats - the developer might as well have a keen sense of what the product vision should be, and might as well make a good enough judgement of what user story to extract from the messy backlog. But as we started to have the devision of labor, the dumpster-style of backlogging became problematic. There, we arrived at the moment to differentiate the product backlog from the dev backlog - and by the way, we need a roadmap too.

A roadmap identifies the customer problem.

Roadmap, focusing on a longer term goal, ranging from 6 month to 2 years, serves for an inspirational purpose; It is not a commitment. Roadmap is strategic - It highlights the source of all the problems - the customer's problem that we're aiming to solve. It lists milestones along the timeline as a promise to the customer what would be delivered at what time, and why. 

A product backlog outlines solutions to the customer problem, and feeds to the dev backlog as a series of dev problems

I found this middle piece to be the tricky one in my organization. The Product Management team is still young and trying to find its stand in between business and development. Collectively we suffered from making the distinction between a customer problem that needs a product design solution, and a development problem that needs a technical solution.

I think it's a genius idea, that in the beginning of the year we decided to inject the UX team into the PM team. More about that in #PCampBoston: Sorting out PM and UX.

A dev backlog offers the solutions for implementation

In the recent few sprints we've gone through, I felt the improvement. Our dumpster-style backlog is getting managed. As we started a Product Management backlog board a couple of months ago, the team started to be more careful about which item goes to which backlog. This has made the development backlog much easier to digest.

Later in the afternoon, Ellen Gottesdiener facilitated a workshop, Agile Product Ownership, touched the similar topic. Unfortunately I missed it for another session. Collected her book: Discover to Deliver.

This 2-minute of key concepts on how product partners conduct structured conversations to discover and deliver high value products. This framework, from the acclaimed book Discover to Deliver: Agile Product Planning and Analysis (see www.DiscoverToDeliver.com), is applied by organizations globally to identify the right software-intensive product to build, and build it right.