Win a Copy of Agile Product Management with Scrum

By Roman Pichler, 19th April 2010

Win a copy of Agile Product Management with Scrum by sharing your favourite product owner story or tip.

RSS Feed

8 comments on “Win a Copy of Agile Product Management with Scrum

  1. Dave Sharrock

    I am just starting to coach a new PO through the release planning process and am again reminded of the special role the PO and release planning plays in agile adoption.

    Scrum teams are often isolated from the processes used across the rest of the organisation – as long as a product feature is delivered and works as expected, stakeholders are somehow sympathetic to the agile process. This is rarely the case for a PO providing estimated release dates. Empirical release dates understood within Scrum teams as estimated and liable to change as the development progresses are understood as fixed dates by other stakeholders. Risk-weighted release dates can be calculated to manage this expectation. However, this is also a great opportunity to introduce lean thinking into other parts of the value chain. The education and interaction required to get empirical release dates accepted in an organisation can lay seeds of change outside the product development organisation, as well as uncovering impediments to optimizing the whole chain.

    • Roman Pichler

      Good point, Dave. Applying inspect and adapt to release planning can be challenging when organisations are used to traditional project management approaches as you point out. Here is something I find very powerful: Invite internal stakeholders including management, marketing and sales to the sprint review meetings and update the release burndown in the meeting. This results in a collaborative release planning approach where the stakeholders are invited to share and contribute.

  2. Steen Hulthin Rasmussen

    My favourite product owner story is not a fairytale. It is about a friend of mine, who is in an organisation where scrum [has been/is being] introduced bottom-up. A product team in the organisation was gradually starting to do scrum. The former project manager of the product was given the role of product owner.

    The sprints went well. The team was showing good results and producing software of better quality. Management saw these result and thought it was good (although they did not really understand what was happening).

    One day the product owner announced to the team that new functionality was prioritised. The product owner however did not read up on what end user actually needed even though there was some relevant information (which the product owner knew about). In stead the product owner mostly guessed on a fairly technical level what should be done.

    The result:
    After almost 2 sprints the team learned about the relevant information and found out that what they had been implemented during these 2 sprints was not really supporting work flow of the users of the product.

    The lesson:
    It is really important for a organisation to understand the importance of the product owner role [as you (Roman) mention in the se-radio interview: Particularly in an organisation where Scrum has been introduced by the developers it is important to be aware of this. Management might not know their role in scrum [they should see: and do not understand the importance of the product owner role.

    My suggestion in my friend’s case would be to point out the cost of lost work for the team compared to the cost of having a product owner who actually represents (and knows about) the business side of the project.

    If I win I feel obliged to give the book to the product owner of my friend.

    • Roman Pichler

      Nice story, Steen! I’ve also worked with product owners who were too inward-focused and concerned with technical details. As you point out, the product owner should be the voice of the customer representing the group of people intended to purchase and use the product. I like your recommendation. What you may want to suggest in addition is to invite customers and users to the sprint review meetings. Their feedback allows the product owner to adapt the product backlog.

  3. Christian Prison

    The most delightening tip I got during my CSPO training: We learned that it might be helpful to “break up” (instead of break down) your product backlog if there are too many entries. I did it and suddenly I was able to keep my overview, find the stories very quickly and save a lot of time.

    • Roman Pichler

      Great tip, Christian! Breaking up a long product backlog into several shorter ones is appropriate when several products are hidden in the original backlog. One of my clients had five product owners but used one product backlog, as they treated their rather complex website as one product. By distinguishing between different applications and viewing each as a product in its own right with its own product backlog, the one big product backlog was history and the collaboration between the product owners simplified.

  4. Jose Papo

    I have a tip for product owners who will work with many stakeholders. When you need to manage the needs and requirements of many stakeholders do focused workshops. You can do a Vision workshop, a product backlog workshop, a detailed user story workshop. In this way you can reach agreement between many stakeholders in a single collaborative session, instead of trying to talk separately with each one.

    • Roman Pichler

      Thanks for the tip, Jose. Nice one! Collaborative workshops are great — as long as the right people are present and the objective is clear. Ellen Gottesdiener explains in her book “Requirements by Collaboration” very well how to run workshop to find, capture and refine requirements btw.

Leave a Reply

Your email address will not be published. Required fields are marked *