Dr. Dobb's Journal - January 2008 - (Page 65) d01ambler_p4ma 11/9/07 10:15 AM Page 65 creation of a Stakeholder Goals Map to capture this critical information that you’ll use throughout the project to guide decision making. The product owner will also work to gain stakeholder support for the project during Iteration 0. They’ll do this by helping to set stakeholder expectations of your Agile project team, educating them on the importance of working software over documentation, the roles and responsibilities of everyone involved with the project, and the importance of active stakeholder participation throughout the project. The product owner often works with the procurement and legal professionals in the negotiation of any contracts required for the project. They’ll also be involved in the initial planning for the project, helping to identify critical dependencies on other teams as well as a potential release date. My July 2006 column (www.ddj.com/architect/ 188700850) covers Iteration 0 in greater detail. At the beginning of each Construction iteration, the product owner is involved with the rest of the team planning out the work. An often-neglected aspect of Mike Cohn’s planning poker (www.planningpoker.com) is the required modeling activities implied by the technique. To analyze the details behind a requirement, the product owner will not only drive the discussion, they’ll also be active participants in any modeling, often whiteboard sketching. This modeling in effect is the analysis and design of the requirements being implemented that iteration. The product owner will also be actively involved with model storming sessions (www .agilemodeling.com/essays/modelStorming. htm), which typically last between five and 15 minutes, throughout the iteration. No matter how good the iteration planning modeling, there will still be a need for business details when the developers go to implement the requirement, details that the product owner provides. Throughout the iteration, the product owner will be in regular contact with project stakeholders, often identifying new requirements or renegotiating priorities. The product owner may be able to provide broad direction, but for any reasonably complex problem domain, they won’t have all of the details and the team shouldn’t have to wait on them to gather and then document the required information. Therefore, it is important for product owners to have a wide range of contacts within the stakeholder community and be able to schedule working sessions with experts as required. You can’t expect all stakeholders to be available on a whim, but it is reasonable to be able to expect to schedule time with experts, even if it’s only via a telephone call or e-mail. Because the product owner represents the team to many stakeholders, they often find themselves demoing the software to stakeholders who don’t work with the team regularly. It’s critical to regularly show visi- ble progress in the form of working software to communicate the work done to date. An “all-hands” demo can help to get feedback from a wide range of people quickly. Sometimes you may identify that you’re in trouble, perhaps some stakeholders are being unfairly favored over others or, worse yet, that the product owner isn’t doing a good job of representing the overall stakeholder community. Sometimes demos aren’t enough. If some stakeholders want more detailed information, the product owner may choose January 2008 l www.ddj.com l Dr. Dobb’s Journal 65 http://www.ddj.com/architect/188700850 http://www.ddj.com/architect/188700850 http://www.planningpoker.com http://www.agilemodeling.com/essays/modelStorming.htm http://www.agilemodeling.com/essays/modelStorming.htm http://www.agilemodeling.com/essays/modelStorming.htm http://www.leadtools.com http://www.leadtools.com http://www.ddj.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.