Optimising Product Management: Agile Strategies and Best Practices


product management in 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.

Tags: Product Management, Document Management and Control, Company News

Paul Walsh

Written by Paul Walsh

Paul Walsh was one of the founders of Cognidox. After a period as an academic working in user experience (UX) research, Paul started a 25-year career in software development. He's worked for multinational telecom companies (Nortel), two $1B Cambridge companies (Ionica, Virata), and co-founded a couple of startup companies. His experience includes network management software, embedded software on silicon, enterprise software, and cloud computing.

Related Posts

The Pros and Cons of Phase Gate Processes in New Product Development

Will a phase gate process hold back or enhance your new product development? What are the pros and ...

Evolving Quality Management: From Ad Hoc to Chaordic

How can you help your business evolve its mindset to achieve the most instinctive, frictionless and ...

Maximising Customer Value Through Lean Documentation

In a Lean approach to product development, customer value is defined as ‘everything the customer is ...

The Importance of Document Control Systems in Business Operations

What does it mean to 'control documents'? And who needs a formal document control system to manage ...

Enhancing Document Management: Why Google Drive Falls Short

Google Drive is a cloud-based program that allows you to create, edit, store, and share documents. ...

Is SharePoint the Right Choice for Your Medical Device QMS?

A Quality Management System (QMS) is a requirement for medical device developers across the globe. ...

What happened at CogniCon24?

On the 16th of May, Cognidox welcomed nearly 100 attendees from across the high-tech, medical ...

Announcing CogniCon 24 - save the date!

The Cognidox team is delighted to announce we will be hosting CogniCon 24 on 16 May 2024. This is a ...

Cognidox announces new e-signature integration with DocuSign

Cognidox are delighted to announce the release of our new DocuSign e-signature integration. The new ...