- Output Products
- Intangible Output Products
- Input Products
- The Workshop Repository
- Tips
- Questions to Ask Stakeholders About Products
- For More Information
This chapter is from the book
This chapter is from the book
This chapter is from the book
Intangible Output Products
In addition to the tangible deliverables, your workshop should deliver intangible outcomes, including decisions, enhanced knowledge, and increased motivation.
Stopping to test for closure—in other words, to make decisions about the state of your requirements—sounds, on the surface, as if it would take valuable workshop time. Actually, it speeds up a workshop. Forcing an explicit decision creates tension as you talk about what is missing, wrong, or important. It requires you to analyze related details. It emboldens communication.
Making decisions explicit requires the group to define ground rules for achieving closure (see "Basic Ground Rules" in Chapter 6). Reaching closure requires that you combine your doneness tests with the use of a decision rule process.
The technique is simple: You explicitly define what needs to be decided during your workshop, and then add those decisions to the list of output products. Ask the workshop sponsor or project sponsor to remind people about it during the workshop kickoff. Typical decisions include the following:
The scope of the project as represented by the requirements
Which requirements, as represented by use cases, will be delivered for the current release
The detailed requirements and their priorities for the next release
You also need to know whether other intangible outcomes are desired, such as people leaving the workshop with increased knowledge or motivation. These can be the healing hidden agendas discussed in Chapter 6. If you specify these outcomes, you must design workshop activities to incorporate ways of addressing them (see Chapter 9).
Note that this might prompt you to revise the list of workshop observers (see "Observers" in Chapter 5). When one intangible outcome is to increase the software team's knowledge of the business, for example, include developers and testers as observers. For one project, one desirable intangible outcome was for analysts and the project leader to become knowledgeable about how to conduct a requirements workshop. We included them as observers; I gave them a list of questions to keep handy while they observed. After the requirements workshop, we also conducted a debrief and an action planning workshop to help them incorporate, in their own projects, what they learned from observing.
When you ask questions about intangible outcomes, you might uncover hidden agendas. When I asked one project leader about intangibles, he told me that the team members were discouraged by prior requirements efforts and were concerned that they wouldn't learn anything new. He wanted to enhance the team's motivation. We decided that it was important for the project sponsor to kick off the workshop and for subject matter experts, not surrogates, to attend.
In another project, the sponsor wanted to increase team members' motivation. In addition to having him kick off the workshop, I facilitated a brief activity in which each person shared his or her professional development goals.