ThereÂ’s no way around it: The Product Owner is part of the Scrum team. Granted, he or she doesnÂ’t do the heavy lifting of actual development, but the Product Owner is an indispensible part of the process. He or she communicates the vision for what is to be developed and defines the criteria by which it will be judged. However, that doesnÂ’t mean that the Product Owner should be involved in every aspect of development. One particularly hard question is whether the Product Owner should attend the teamÂ’s daily Scrums (or daily standups). And the frustrating answer to that question is: It depends.
If a Product Owner attends these meetings and attempts to redefine goals or scope, then itÂ’s probably a bad idea. In by-the-book Scrum, the Product Owner can attend these meetings, but cannot speak. And if the Product OwnerÂ’s attendance is disruptive, the team reserves the right to request that he or she not attend. Any time the teamÂ’s ability to self-organize is jeopardized, the Product Owner definitely should not be attending these meetings.
However, if the Product Owner truly understands the limitations of the role, he or she will respect the teamÂ’s ability to self-organize. In this instance, a Product Owner who attends daily Scrums can be an incredibly valuable asset. He or she can tell the team if itÂ’s on target or heading off-track on a daily basis, rather than only at the Sprint Review Meeting, resulting in a hyper-adaptive work cadence. But, again, this kind of high performing team depends upon the Product Owner and his or her ability to resist the urge to act like a traditional project manager.
Posted under Scrum
This post was written by admin on October 13, 2008
Hi,
I was very impressed on the Article on Agile Methodolgy,however I find The terms Metrics for each Iteration missing. As Agile suggests iterations or sprints are there any special recommended ways of monitoring performance results……….
Hi Pryanku,
Thanks for your comment. I’m glad you’re enjoying the articles. As for metrics… Yes, agile methods often require a different set of measurements than those used by traditional project managers. However, there are many different metrics (which ones you use depend on your business, what you want to measure, and countless other variables) to choose from. But keep this in mind: The metrics should reflect the values of the management model you’re using. For example: In the case of agile methods, which emphasize teamwork over individual heroics, metrics should focus on the team’s performance, collectively. It would be contrary to agile principles to break that down into individual metrics. I’ll try to write a post or two on agile metrics soon.