What is it?
The In / Out List is a project work scoping device discussed by Alistair Cockburn in his book “Writing Effective Use Cases”, which he also covered in an article about the book. It’s very simple to create and use, and facilitates discussion among stakeholders on exactly what is in or out of scope.
Why do it?
According to Cockburn, the benefit of the In / Out List lies in both its simplicity and it’s ability to foster discussion and consensus among stakeholders. By creating the List as past of early stakeholder group discussions, you immediately surface disagreements about the scope of the work to be done and possibly even the objective of the work.
How do I do it?
Creating an In / Out List is extremely easy and can be done in just a few simple steps.
Create a 3 column table with the first column being wide enough to enter a short statement, and the second and third columns just being wide enough to enter a 3-letter word.
Label the first column “Topic”, the second column “In”, and the last column “Out”.
Enter the first topic you wish to discuss on whether it is in or out of scope into the first row of the Topic column. This should be reasonably specific, such as “creating an invoice”, but can start out at a higher level and eventually be refined.
Discuss among the stakeholder group whether the topic is in scope or not. Once a consensus is achieved, mark the appropriate result column (the “In” or the “Out”).
Repeat as necessary until the overall scope is relatively clear and all known areas of potential disagreement are addressed. The current version of the In/Out List should be available during any project team / stakeholder / or sponsor meetings and can be updated on the fly as new issues are found or if old decisions need to be revisited.
What Should the Results be?
The result should look something like the table below:
|Payment Processing Hardware||Out|
|Analysis of Current Systems||In|
|Delivery Management System||Out|
Or you can check out this actual In/Out List that was created for the Robert C. Byrd Green Bank Telescope.
The greatest advantage of this technique is it’s simplicity. It’s easy for anyone to understand and it’s easy to maintain.
The are two potential disadvantages to the In / Out List that come to mind.
- It’s simplicity and a tendency to think in big “chunks” of scope (such as “Invoice System”) may make it easy to overlook areas of disagreement among stakeholders when finer details of those scope areas are examined.
- Unless some effort is made to re-order the list occasionally to put related or sub-topics together, it can be hard to quickly scan the table to figure out if something is in scope or not.
- As mentioned above, make sure you revisit the In / Out List frequently. As more detail is understood of the potential project scope and impact, the List should be revisited and updated.
- You can have separate In / Out Lists for different aspects of project. Maybe one list for the overall project effort, and perhaps another for the solution design effort (especially certain existing systems must be used or leveraged).
- You can leverage the In / Out List structure for more than project work. You can use it for meetings to help keep discussions on track (to communicate what should and should not be discussed), for focusing brainstorming sessions, or other activities where there are group discussions that you need to get agreement on what is to be covered.
- Article – Use Cases: Defining Scope. By Alistair Cockburn. InformIT. March 22, 2002
- Book – Writing Effective Use Cases. By Alistair Cockburn. Addison-Wesley. 2000. Pgs. 35-36