Category Archives: backlog

5 Musts of Requirement Management

Requirement management is perhaps the most common task across the product management community. Fundamentally the role of a product manager has evolved and also revolves around ‘Requirement Management’. This task has been so common to the role of product management that many identify Product Managers as Requirement Managers. What customers need and what organizations develop should be aligned else there will a mismatch between demand and supply and this probably is the least possible expectation from a product manager, ‘supply what customers are looking for’.

A product manager can and should never go wrong with managing requirements. Irrespective of the technology, domain, organization or the country of work there are certain fundamentals which a product manager must always stick with or else be prepared for a nose dive.

Requirement management involves aspects of gathering, tracking and prioritizing requirements. Here are some simple yet powerful data points that a product manager should always record against a requirement: Continue reading

Backlog Elaboration: A Win-Win Proposition

As we all know, Product Managers are responsible for maintaining the Backlog such that it reflects the demands of the market. As market dynamics change, the backlog changes too. The Agile way of constantly prioritizing the backlog and keeping the most relevant features or stories at the top are key to ensuring that the product stays competitive in today’s dynamic market.

Many times, the Product Manager and the Product Development team go into Sprint Planning without enough clarity on some features or user stories. This causes the planning meeting to go in circles Continue reading

Hey Product Manager, is your backlog mature?

As the world embraces the Agile methodologies with gusto, it is important to get certain elements right to ensure that the key Agile principles are properly implemented. One such element is Transparency. A mature Product Backlog goes a long way in ensuring transparency.

For the beginner, a Product Backlog is a wish list of features or enhancements that would make your product great. It contains User stories which are features or enhancements written in the language of the end user. Contrary to Waterfall projects which have a baselined and frozen list of requirements, the Product Backlog is kept alive and constantly modified through the life of the Product. It is this changing nature of the Product Backlog that is both an asset and a potential liability. It is important to ensure that the Product Backlog does not become just a stale document of EVERYTHING that might or might not get implemented in the product’s lifetime. It is the Product Manager’s responsibility to maintain a mature backlog and once done, everyone involved in the organization stands to gain from it.

3086708145_5ed56e5e5f

With this background, I shall now attempt to define the characteristics of “A Mature Product Backlog”.

Valuable User Stories: A Mature Product Backlog contains user stories that deliver value to the customer. Each user story should take the product one step closer to the product that the end user desires. Additionally, each user story should have Acceptance criteria clearly listing the boundary conditions, performance criteria and other quality expectations.

Prioritized Backlog: The Product Backlog should be prioritized by the Product Owner in terms of the highest value stories at the top of the list. Another factor to be considered is the Risk involved in implementing the user story. It is a good idea to categorize user stories on Value and Risk and then prioritize the backlog on Value first and Risk next. High Value Low Risk stories would be at the top with the Low Value High Risk stories at the bottom.

INVEST(ed) User stories: A mature Product Backlog has user stories that follow Bill wake’s Independant, Negotiable, Valuable, Estimable, Sized appropriately and Testable (INVEST) mnemonic.

A definite list: The backlog is a list of user stories that will make your product great and it is not possible to only have a certain number of user stories in it. However, instead of having an endless list of small and big features, all I want you to do is a) Keep features that are due to be implemented in the current Release very detailed, b) Group similar features that are part of future releases into Epics and c) Keep user stories from future releases big and break them down into smaller user stories only as you come close to implementing them.

Estimated User stories: This is an Optional requirement for a mature Backlog. It is great to have a Product Backlog with user stories that are assigned story points to determine the size and effort involved. This helps the Product Owner in prioritizing the user stories. For estimating a large number of user stories, Planning poker could be ineffective and the Affinity estimating technique will be a better method.

Over to you now. do let us know if something is missing in this list.

(Pic: Thanks to Flickr: Creative Commons for the Backlog pic)

Interviewing Agile Product Manager

elephantTrust me, this has been most crazy of all interview rounds that I have been doing for quite some time now. Objective is to hire a product manager who has experience of delivering successful product release via agile methodology. Initially I felt that I am lucky to get so many CVs (candidates) with agile experience but as I started talking to these so called experts in agile, I started banging my head on the wall, and here is answer to WHY I did so.
Continue reading

Maintain Backlog Quality, #pmantra

You are a real good product manager who loves to listen to people and likes to hear ideas from all the corners of the office. You note down everything, dump them on the backlog and then pull your hair when the product backlog grows exponentially. Aha! what the heck! what happens to my customer meetings, review meetings, competition study, etc.

It is worth mentioning here that, just as, all that glitters is not gold, all ideas cannot be sold. It is the role of a product manager to assess which idea is worth selling and which goes to the trash bin. Product managers should maintain the quality of product backlog by exercising all  due diligence to avoid non-relevant requirements from entering into the backlog. Continue reading

Inspect and Adapt for Agile Product Managers

As organizations make their movement from Waterfall to Agile software development, a shift in culture takes place. One discipline that is most affected in this whole change is Product Management. They have to cope up with the demand for more releases within the same time and each release has to have meaningful content.

I have tried to list the traits needed for a successful Agile Product Manager here. Continue reading

Case Study: Product roadmap hijacked!

Last week Rich, the product manager of a B2B enterprise product, had finished the release planning of the 1.0 version of the brand new product line that he was managing. The release of the product was two quarters away and this week he was busy interacting with the engineering team on the finer details of the interaction design since the first iteration had just been kicked off. Rich was in general happy that content for the first release was more or less firmed up after a series of research on the competitive landscape, customer needs, technology evolutions and others.

Rich reported to Sunita, Director of Product Management and they had good working relationship. On Thursday when Rich was about to leave for the day, Sunita came over to his office and asked him if they can meet on something urgent. Continue reading