In Agility, Or A Pig On Roller Skates? Ken Schwaber comments on the role of product management / ‘the customer’ in Agile projects: The backlog is the result of actual work managing a product, and should be used to increase agility (ie. flexibility in getting higher value items out first), not just to adapt to a different development process.
Usually, the introduction of Scrum is initiated by the development organisation. Whether it is completely bottom-up, initiated by the developers to get more grip on their process, or more top-down by development managers interested in increasing productivity and work satisfaction, the initiative is mostly from development. This is both odd, and something of a problem: The main focus for Agile is to get the most value for the customer as soon as possible. This should be of huge interest to the customer, usually product management. But it often isn’t. Perhaps because the principles are not very well understood, or perhaps because any project manager has now been trained in distrusting development teams and their management because what is asked for is usually not delivered.
Years of waterfall, with very high penalties for changing or adding requirements after a project has started development, have conditioned product managers everywhere to create requirements documents in which every possible little thing that might ever be wanted is listed. And of course everything in those documents is Must-have, or at the very least Should-have (MoSs grows, CoWs get eaten), otherwise you might as well not put in there at all!
Going from that requirements document towards a backlog is easy, simply make a separate user-story for each of the requirements in there. Strict priorities are a lot harder, and you notice a lot of attempts to wiggle out of having to make those choices. However, to go from that big document towards a backlog, and then doing some reality-based release planning is very hard, especially when trying to determine minimal sets of features that are actually useful for your users. Simply going through the full list (even when leaving the CoWs out in the pasture) to get to the full release ‘1.0’ is not going to give you all the advantages that you could be having from adopting Agile. Thinking in smaller feature sets, and smaller releases is needed to get to the type of flexibility that well get you the competitive edge that you are (should be) after.