Product Management in an Agile style

The Software East group continued its series on Agile software development with a talk by Scrum consultant Roman Pichler (@romanpichler) on "Managing The Product Backlog". Roman's slightly unique angle on Agile/Scrum is that he focuses on the way that it impacts Product Management as opposed to the software development team. It comes as no surprise therefore that he has written one of the few books on the subject, "Agile Product Management with Scrum: Creating Products That Customers Love".

What's the problem being addressed here? It's the scenario where an organisation, utterly fed up with slow and unpredictable product development cycles, decides to switch to an Agile / Scrum development model. So all of the stakeholders send their epics and user stories to the product owner, and the first thing that becomes obvious is that there is a mountain of things to do. Or, having used an Agile process for a while, the list of un-started jobs grows and grows. In both cases, this is the "product backlog".

Roman offered a more operational definition of a product backlog: it is the outstanding work to create the new product. Product backlogs tend to be large.

It isn't a good thing to own an out-of-control and unwieldy backlog. Like a garden or a hairstyle, it needs to be regularly groomed. Roman's talk covered practices to manage the product effectively: discovering and describing requirements in Scrum; prioritising the backlog and getting the top items ready for the next Sprint planning meeting.

In a way, the Software East meeting was like a product development. We'd all come together with different expectations and aspirations on what we wanted from the meeting. We collectively hoped it would be coordinated and work itself towards a conclusion that we all (more or less) agreed upon.

It was therefore a clever idea on Roman's part to start with a meeting / session backlog analysis. We all wrote one question or need on a post-it note and stuck them on a wall. Just like a software feature list. By working with this backlog we were able to proceed from the clutter of ~30 ideas to a structured meeting.

How? The first step was to bunch the notes into clusters or groups e.g on grooming, setting priorities, etc. Roman said that the size of groups gives a useful first cut at priority. It's important to focus on essential items, not a wish list. It's useful if the backlog items are sized by complexity. It's essential to get regular user feedback on any grouping and prioritisation. It's helpful to keep the whole process visible - hence the wall & post-it notes.

It's important to start with a product vision - for whom is this software intended, why would they buy it? The top features are likely those that directly influence the product revenue model. Starting with a sketchy backlog starts to detail the vision. It's normal that the backlog changes = this is Agile. We are striving for a minimal marketable product (note the substitution of "marketable" for "viable"). It's better if this is defined as the right product for a small group of people, as opposed to any alternative.

So the steps in grooming a product backlog for the current sprint are: discover, describe, adjust & remove, prioritise, estimate, and finally get the backlog ready for the following sprint.

Roman re-iterated an idea (from Mike Cohn) that the product backlog would ideally be DEEP: It should be Detailed appropriately, Estimated, Emergent, and Prioritized. More on that from his blog.

One of my interests is what tools might be used to assist in all this? What's the place for documentation? Roman was of the view that detailed requirement specifications are gone, a thing of the past. Tools are probably not required, and a database containing un-used requirements is a waste that contradicts Lean project thinking. He did feel that a spreadsheet is a useful tool if the team is not co-located. Personally, I take on board the sentiments but am not so convinced that tools wouldn't help.

Finally, one of my other concerns about Agile was explicitly addressed: how does an Agile product capture the non functional requirements as well as the functional user stories? He talked us through a graphical layout model (hard to reproduce here) that gave screen space for things like speed, performance, usability and availability. So it definitely should be part of the PM's analysis.

All in all, a very useful session from someone who clearly knows his subject.