Unlocking Potential

In most organizations it is not sufficiently possible for a group of equals to reach consensus on a continuous basis to decide about how a goal should be reached. Having one person with the responsibility for the final decisions allows for faster decisions and more continuity.

The Product Owner often combines the role of a product manager with profit/loss-responsibility and several responsibilities of a project manager. His main goal is to create value, driven by the Product Backlog.

Using an agile approach usually relieves Product Owners and their supporting organization of a number of tasks as developers are supposed to fill in gaps based on their experience and knowledge. However, product-related decisions still need to be done by product management, especially as they are strengthened in their role Product Owners.

Requirements can be communicated successfully if they are short and focussed. However, supporting specifications are required in a lot of cases to show the way when developers dig into the details. Usual formats for agile requirements are user stories and use cases. Especially the user story format allows to write very short requirements and may lead to incomplete analysis by the Product Owner. So ensure that the requirements are fully analyzed before they are communication to the team and that enough information is available to start implementation without additional business analysis by the team.

Traditional estimates of project work packages focus solely on mandays and if the project is managed with mature processes, risk is dealt with in a risk register. Complexity of work packages is usually ignored and managing two or three of these dimensions separately leads to continuous rework of the project management plan.

Estimates based on effort, risk and complexity are usually calculated in Story Points or Estimation Points. Using Planning Poker or the Team Estimation Game with Fibonacci numbers as Estimation Point classes provides for quick estimates while ensuring independent results by each expert.

According to the Pareto rule, 80% of the business value is created by 20% of the requirements. The same applies for features vs. development costs. As there is only a single customer, decisions about the priority of each requirement are possible, although it might not be easy.

By sorting all requirements and realizing them in that order, the most important requirements are already done when the question arises, if the implementation of further requirements is recommended based on their value compared with the required effort/budget.