Why am I uncomfortable with Product Backlog?


Though I am a strong believer in Agile process, I always get a feeling that a product backlog does not give the full picture of the expected product and we need something more to define it.

Let us first look at how product backlog is prepared?

  1. You start with either a business problem or a product idea – and you decide to build a piece of software
  2. You probably write a very high level specification of what the software should do
  3. A product owner is identified who breaks up it up into multiple stories on how the user is going to use the software
  4. Stories are prioritized and build one by one
  5. At each stage the software is reviewed by product owner – and any required course correction incorporated
  6. Once all the stories are completed the product is ready

Essentially, what we are doing is:

  • Define the problem
  • Break it up into smaller parts
  • Solve each one individually
  • Put it together and hope that it solves the original problem

Yes, I know we iterate – and in theory iteration is suppose to reduce the gap between “is” and “should be”. But the big question is do we accurately know the “should be”?

That brings us to the debate between “Designed Solution” vs. “Emergent Solution”. We all know that Linux has emerged – that Wikipedia has emerged. However, what we forget is that for a good solution to emerge we need to try out many alternative and select the best. Here is an interesting quote from The Cathedral and the Bazaar by Eric Steven Raymond

“…you often don’t really understand the problem until after the first time you implement a solution. The second time, maybe you know enough to do it right. So if you want to get it right, be ready to start over at least once”

In a commercial situation, how often do you have this luxury? How often can you try out multiple ways of doing the same thing?

What is the alternative? To have somebody who understands the problem and understands what the solution should be. The product owner is supposed to be that person (see this).

However, this only means that the solution will be as good as the product owners understanding of the problem.

Does this not tilt the solution to “Designed Solution” rather than “Emergent Solution”? Does it not put too much responsibility of the shoulder of the product manager?

Udayan Banerjee on Google+

Related Article

 

About these ads
Comments
10 Responses to “Why am I uncomfortable with Product Backlog?”
  1. srinivas C says:

    The answer to your penultimate question is “it depends” on the understanding the PO has of the market, understanding of Scrum, the atmosphere and capabilities of team members and other collaborators. By itself the backlog doesn’t tilt things either way, but allows a tilt to what is pragmatic, or seems pragmatic. To your last question (if by product manager you mean PO), yes indeed! and that is the point. PO’s is the single wring-able neck. So the PO needs to be an excellent collaborator, if not, so be it, it’s his/her neck.

  2. Stephen Reed says:

    Your point is valid, and obviously comes up in our heads as relevant to our situation (that is why we have come and read your blog most likely).
    Previously I have read a lot around the start up phase, how architecture should be done etc etc. In real teams I have seen how the team needs to have the vision of the Sponsor / PO at the beginning with an overarching architectural view of how this thing should be built or integrated with whatever.

    During the sprinting and development process there will be many (many) gatherings of the PO and Team to discuss whats next, what we have built and how it all ties in with that original vision / architecture, however, the team also designs and redefines the architecture according to the need of the sw development and according to best practice / standard that they come accross as the get closer to the work to be done. In a sense – emerging arcitecture and design of the product.

    We do agile because we know we are dealing with an environment in sw development which requires an empirical approach. Our PO knows what they want, but they dont know what they want (until the see it) and therefore I would say we get closer to the desired solution because we also focus on the top value items first (and attack the risky bits up front).
    On the PB we should have all the standard stuff thats going to need doing in addition to our desired piece of functionality – DR planning, Support handover, BCP updates, Performance stories (I am talking about an Enterprise env here). And the PB is emerging, we cant set fixed dates normally because there may be new pieces of work we identify or items may become not needed as the PO sees the functionality and decides – we stop here!

    So I guess what I am saying is, if you have a good team that is considering all of your valid points above, and some of mine, plus keeping up with the play on external influences (if you are in an Enterprise, or if your market is changing) then you should be good. Alternatively if you feel this way, maybe you should go back to the old way of planning and defining the problem and stick with that – if you are more comfortable with it.

  3. By my opinion ine important issue is missing: The product vision.

    Following the vision, it also often happens that product backlog items are dropped completely, as the development will become mostly drawn by the vision and not anymore by a collection of (sometimes unrelated) backlog items.

  4. Rukshan says:

    Some thing that worked.

    We were able to convince a client that the first run would be a fast tracked (less emphasis on coding standard, scalability etc) development to understand the features. one easy point was that the client itself was not sure what he wanted, at least ha trouble in putting it down on paper, defined.

    Once the fast tracked development (iterative – we must have released over 15 versions to the staging), we did a recoding – the developers exactly knew what to do and also the business were able to talk of features to come, so the architecture could leave room for that. (eg: web services connecting to other applications etc).

    Recoding is done. Almost 25% of the time as the first run. Its about to be swapped with the application that is live.

  5. I don’t think product-owner defines the user-stories in isolation. In planning meeting team has a good amount of discussion with product-owner to understand the user-stories and at that time (as part of the brain-storming) team provides various options from technical feasibility points of view and also validates its business relevance. Only when team considers the user-story as READY from required based on provided information, it starts implementing it. Off-course based on the demo, product-owner can ask for modification in the given implementation.

    Sometimes, when product-owner is not sure about the solution, team works out prototypes (sometimes mockups) for various options and based on the feedback implements the solution. In essence, by definition there needs to be extensive communication between product-owner and team and product-owner doesn’t work in isolation.

  6. The whole issue you mention of “Put it together and hope that it solves the original problem” has been raised before. Jeff Patton calls it “mulching the backlog”:
    http://agile-commentary.blogspot.com/2008/10/dont-mulch-your-backlog.html

  7. Sanjay Patil, NTL Mumbai says:

    The product owner should have good market survey about the product/solution & can able to preference those benchmark while building the product.
    e.g. XYZ company launches a new car
    Then Product owner put down the market survey with other stakeholders with order
    •Cost
    •Luxury
    •Performance
    •Car Segment (Small/Big)
    Now other stakeholders allocates the task accordingly which satisfy the product owner dreamed car

  8. Deepesh says:

    “the solution will be as good as the product owners understanding of the problem.” – My argument …Product owner is only a idea..a position, whereas the decision of what goes into the product comes from different stake holders , which gets collated , structured and prioritized by the product owner.

Trackbacks
Check out what others are saying...
  1. [...] Why am I uncomfortable with product backlog? [...]

  2. [...] Can good design / architecture emerge? Just adding feature after feature may not be sufficient – Why am I uncomfortable with Product Backlog? [...]



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 986 other followers

%d bloggers like this: