R.P. Churchill.com

The definition given in the BABOK is, “A user story represents a small, concise statement of functionality or quality needed to deliver value to a specific stakeholder.” This is a very general definition and is potentially different from a task assignment. These are usually employed during the requirements phase, whereas tasks may be assigned in any phase. I discuss a way to think about these activities and how to track them here.

A classic user story is often written in the following form:

As a role , I would like to take some action so I can achieve some result .

This format can be thought of in terms of who, what, and why. “Given… when… then…” is another possible format. I opine that requirements especially, and tasks more generally, should be written in any format that yields the correct results. As long as the person or persons assigned the requirement or task accomplish the desired thing, the expression is “correct.” I share this because some people may demand that (especially) requirements must be written in a particular way, and I think such demands miss the point.

So what are we trying to communicate in these stories?

• Stakeholder Needs: The stories attempt to provide chunks of future capability that serve stakeholder needs.
• Solution Needs: Some stakeholder needs cannot be fulfilled without supporting capabilities that may not have been identified by the stakeholders. These often take the form of technical and other indirect prerequisites.
• Prioritization: This describes the order in which things must be done. This can be expressed as a directly scored parameter (e.g., high, medium, low) or indirectly through processes like backlog grooming.
• Estimation: This can involve costs in time and various resources and also benefits. Being mindful of both supports cost-benefit analyses.
• Solution Delivery Plans: Defining what is needed begins to define how it can and should be delivered.
• Definition of Ready: This is a measure of how clear and complete a story has to be before it may be assigned to be worked on.
• Definition of Done (Testing Requirements): An almost limitless variety of tests may be performed on units of delivered value. This definition says something about the tests the delivered value must pass.
• Value Delivered: This defines the value of the capability delivered. It supports a wide variety of analysis.
• Traceability (within the logical design hierarchy and across phases): Each story should relate to other ones in ways that make logical sense.
• Subsequent Analysis: Developing and prioritizing stories may help clarify existing stories and illuminate the need for new ones.
• Units of Project Management and Reporting: Organizations need to be able to manage resources (time, money, materials, labor, and environmental factors) to understand how much they can accomplish relative to what is desired.

User stories should ideally have a number of desirable attributes, as often enumerated in the acronym, “INVEST.” They should be Independent, meaning that the descriptions should lead to creating the right outcomes no matter what else is happening; Negotiable, in that a team can employ examine related trade-offs from many points of view; Valuable, so they are seen to provide provable benefits; Estimable, so the team and identify the relevant costs across all resource types; Small, so they can be worked in manageable increments; and Testable, so they can be demonstrated to meet standards defined for them by the relevant parties.

Larger stories should ultimately be broken down into smaller ones until they are of proper granularity. Some of the criteria for breaking down user stories is summarized here. They can and should be examined and broken down (or rightsized) when enough is known to conduct a proper analysis. Ideas can enter the effort at any scope and scale. Larger-scale ideas are sometimes referred to as epics. Those can be broken down into individual user stories, and those can be broken down into potentially multiple tasks.

One the one hand, calling these items user stories might be a little goofy. This indicates that the main way to describe needs for an effort is in terms of what benefits users. One the other hand, what other standard of value should there be? I think some of the confusion stems from the fact that user stories and the tasks needed to implement them, as well as the epics groups of stories may comprise, are often discussed somewhat interchangeably. As long as we are careful to define terms and otherwise be clear, this should not pose too much of a problem.

This technique involves engaging a group of people in a structured activity that allows them to develop shared understanding and insight into a problem or solution. The activity is usually conducted in three steps: introduction, rules, and beginning; exploration via communication and iteration; and closeout, assessment, and ranking. Once the most promising idea or ideas are identified, the team can move forward based on that knowledge.

I bolded the idea of communication and iteration because that is the biggest idea and I revisit it over and over. Everything in my framework is based on this, as are many if not most of the techniques listed. The purpose is to get the largest possible volume of ideas generated by the greatest number of — and widest variety of — participants, each of whom bring potentially different expertise, needs, and insights. The more ideas generated, in an environment of enhanced and shared understanding, the better solutions will be developed. This kind of shared participation can also enhance buy-in from all parties.

It is often useful to have a neutral facilitator in charge of running the activity. This may mitigate against any individual or small group with an agenda to exert undue influence on the direction the activity follows or time the activity continues.

The BABOK describes three of the most common collaborative games, although many more are possible. Interestingly, the activities described in the BABOK tend to drive to solutions to specific problems, while many of those listed elsewhere (I love the Spaghetti Tower exercise from the second link, above) are geared more to team-building and are often used as icebreakers in workshops I’ve attended.

• Product Box: The team creates text and graphics for a notional package that the product would be delivered in. This gets the group to think about what is most important to communicate in terms of features and, ideally, benefits. The information is often drawn directly on a cardboard box in a constructed or an unfolded flat form, but the team might also consider alternative materials, dimensions, proportions, and materials.
• Affinity Map: This is one of my favorite activities of all time, and typically involves writing ideas on Post-It notes and then arranging them into groups based on similarities of different kinds. There are many possible characteristics by which items may be grouped, and the exercise helps the participants better comprehend the range of possibilities and which of those are most important. By way of illustration, I will refer you to this post, which relates the story of how I tried to classify all my Lego pieces when I was a young teenager.



• Fishbowl: In this activity, half of the participants discuss the topic at hand while the others watch, as if the observers are watching people discuss something in a fishbowl. The purpose is that the observers may see biases, things that are left unsaid, other possibilities, and other potential errors of omission and commission. It may be useful to exchange roles and repeat the exercise a second time.

Again, all the exercises described, whether to gain insight into a specific problem or allow people to practice communication and get to know each other, are about fostering communication and iteration.

This technique, as described in the BABOK, is about evaluating the stability, suitability, and capability of individual vendors. This information can also be used to compare vendors, using any number of qualification/disqualification criteria and scoring systems (e.g., the first three analyses discussed here), but this article is about what the major criteria used for evaluation and comparison are.

Vendors, of course, are organizations (or individuals) that provide goods and services that your organization does not, or that supplement your offerings when you have limited capacity to deliver. Vendors can be engaged to provide those goods and services to you or your organization, or to a customer you or your organization are serving.

Both the goods and services provided by the vendor, and the vendor itself, may be evaluated. Different criteria may be evaluated based on the situation. The BABOK concentrates mostly on the quality and health of the vendor. I would guess that evaluation of their offerings falls under solution evaluation, in general, which is why it isn’t addressed much in this section of the Techniques chapter.

The criteria for judging the vendor are listed as:

• Knowledge and Expertise: This measures what the vendor knows and how well it can apply that knowledge.
• Licensing and Pricing Models: This must be judged based on the anticipated usage scenarios, especially when the technical capabilities are not strongly differentiated. There can be many combinations and permutations of deployment and access configurations and all need to be compared using a similar cost-benefit analysis.
• Vendor Market Position: This can reflect the relative popularity and success of a vendor, and can also affect how important you and your organization may be to the vendor. There may be varied benefits from being part of different customer communities.
• Terms and Conditions: These involve the continuity and integrity of the provided products and services. This can affect future decisions to change vendors, how sharing and confidentiality of both organizations’ data is handled, how disputes and modifications are to be handled, and how updates and features and delivery are to be managed.
• Vendor Experience, Reputation, and Stability: This involves the impressions of other customers and competitors, the attitude of the vendor’s representatives, and the financial stability of the vendors. Your organization should also plan for contingencies to act upon if any of these characteristics change over time (especially if such changes are sudden and for the worse).

Many different tools can be used to describe different kinds of stakeholders. In general, a stakeholder is anyone involved in or affected by any organizational activity, across the entire potential life cycle of that activity. This encompasses the design and implementation of an organizational process, along with its execution and maintenance.

A stakeholder list is no more or less than an enumeration of the different participants, usually in terms of their roles. Important distinctions of classes of stakeholders are internal vs. external, creator vs. user vs. manager vs. maintainer, type of implementation specialist (programmer, graphic artist, database specialist, content and story analyst, etc.), provider vs. customer vs. experiencer of externalities, and so on. (Which other divisions can you think of?)

Stakeholder maps come in two forms, a stakeholder matrix and an onion diagram. A matrix essentially contrasts two continuous scales, the level of influence of the stakeholder and the impact on the stakeholder (i.e., how the stakeholder affects others vs. how they are affected by others).

Stakeholder onion diagrams show which participants have the most affect on or are most affected by different systems or solutions. While the roles may vary in their specifics, they don’t really change in character. It’s also true that customers, who are presumably represented in the outer ring and thus least affected (or drive the process the least) can be internal personnel and may also be the primary beneficiaries of the new or modified system, whether directly or indirectly.

Stakeholders may further be classified using a RACI matrix (or a responsibility matrix), which describes whether people in different roles are (or should be):

• Responsible: These individuals are charged with performing the requisite analysis, implementation, testing, and deployment required to effect the desired system or modification.
• Accountable: This individual (of whom “There can be only one!“) is held accountable for accomplishing what is desired.
• Consulted: These individuals provide input into the work to be performed, but neither perform it nor are accountable for it.
• Informed: These individuals are notified about what is happening and what has happened, but otherwise how no input or responsibility for the work. They may, however, be the ultimate users or beneficiaries.

Finally, stakeholders of different kinds, most typically users, may be defined in terms of personas. Many different kinds of people may interact with systems and processes in different capacities, and their duties, privileges, and interactions need to be defined in appropriate detail. All envisioned personas must be identified during the analysis so their needs may be properly addressed in the new or modified system or process. All of the tools of business analysis can be applied to ensure this analysis is thorough and accurate.

A business case is essentially a cost-benefit analysis of taking a given course of action. Actions may include embarking on new projects, acquiring resources or other organizations, making non-routine purchases, adopting new methods, entering partnerships, seeking new lines of business, and so on.

A business case may be constructed just like any other project, except the implementation and test phases aren’t part of this named effort. That is, you do everything you would normally: identify the problem, figure out what’s going on, identify needs, assess risks and constraints and assumptions, and design potential solutions. If the benefits of the solution outweigh the costs, either at all or by some specified margin, then the course of action is pursued.

The BABOK describes the process this way:

1. Need Assessment: This defines some capability or improvement that may drive a benefit to the organization.
2. Desired Outcomes: This is a description of the benefits realized, which can be expressed in terms of time, cost, or quality (or features).
3. Analyze Alternatives: This is where you assess the costs and benefits of one or more potential solution approaches. This corresponds to the design phase of any project (possibly in conjunction with the conceptual modeling phase).
• Scope: This is where the size and boundaries of the proposed effort are determined. These define what will and will not be included in the analysis. It also helps analysts choose where to break larger problems down into smaller and more manageable ones.
• Feasibility: This analysis determines whether something can (practically) be done at all. This can be done from a technical or logistics point of view, but the major overlap is with the various financial analyses.
• Assumptions, Risks, and Constraints: I include this in my larger list of project activities, and near the beginning, but I don’t include it in the streamlined, stylized diagram of my framework. That’s because it isn’t really a standalone activity, but takes place in potentially every phase throughout the entire engagement.
• Financial Analysis and Value Assessment: This often involves a full cost-benefit analysis expressed in financial terms, but many judging and scoring systems can be used. For example, a weighted multiplicative system can allow alternatives to be compared both directly by feature and personally by perceived importance.
4. Recommend Solution: Choose the best option – or not to proceed at all.

Prototyping is the act of mocking up some aspect of an envisaged product or capability in order to asses its suitability, acceptability, or performance. It is usually applied to product design, but can be used in many different contexts for both internal and external customers. Successive iterations of a prototype, either as throw-away one-offs or through evolutionary modifications, help determine whether requirements have been properly expressed and understood, the item can be manufactured efficiently or at all, contains all desired functionality, is comfortably usable (ergonomics), is understandable and intuitive, and so on. Prototypes may be physical objects, systems, arrangements (or layouts), environments, or procedures.

Prototypes can be used in proof-of-concept exercises, to determine whether the desired outcomes or effects can be achieved. A form study prototype can be used to evaluated fit and finish, manufacturability, ergonomics, material requirements, and other things. A usability prototype may be used to examine user interactions and comprehension. A visual prototype can bee used to assess how an item looks in terms of its visibility (potato peelers with potato-colored handles are more likely to be thrown away with the peeled skins, which may or may not be a good thing depending on your point of view) or appeal. A functional prototype is used to see how things work.

Methods of prototyping include the following:

• Storyboarding: This allows investigation of the order, location, appearing, and arrangements of things and events. Movies are often storyboarded before production begins, but the technique can be applied to any series of events.
• Paper Prototyping: This involves the creation of one or more drawings, which may be done to any degree of accuracy or scale, to see how things fit together and build shared understanding.
• Workflow Modeling: This describes the flow of operations, decisions made and criteria required to make them, execution brances and diversions, and so on. They are often defined as flowcharts.
• Simulation: Objects, and systems can be simulated when it is too expensive, time-consuming, or dangerous to build and exercise them in the real world. A wide variety of simulation techniques may be employed for this research (e.g., different kinds of analog, continuous, discrete-event, and hybrid simulations).
• Physical Models: When in doubt, build something real and see how it goes.

Examples of prototyping:

• Wind tunnel testing: This is applied to air and ground vehicles and also structures both singly and in groups. Water-borne vehicles are similarly tested in large tanks.
• Flight simulators: These can be used to test physical performance characteristics of aircraft and also operational procedures.
• Full-scale functional prototypes: Entire cable channels and museums are devoted to all the crazy flying aircraft that have been produced to explore various ideas and capabilities.
• Ergonomic studies: Hand-held objects are often studied and designed with a keen eye toward comfort, usability, and safety.
• Simulations of border crossings are used to understand ongoing issues and the effects of proposed changes, and also in the process of designing and building new ones.
• Architects often build building models and landscapes out of foamcore and cardboard so customers can viscerally understand the look and feel of a proposed structure and its environment.
• Building Information Systems (BIMs) like Revit are used to specify the design of a building and its fixtures and infrastructure in great detail. This supports defining bills of material, construction order and requirements, skills needs for all the different components and systems, site preparation and staging, and so on.
• User Interfaces for computer software can be mocked up using tools like Balsamiq, Visio, or UI-builders included in different programming products. They make involve greater or lesser degrees of working functionality.(/li)
• The command module simulator was famously used to identify a procedure that allowed the Apollo 13 spacecraft to be safely shut down and restarted, which allowed the crew to make it back home safely against long odds.(/li)

It is important to note that prototypes may turn up unexpected causes and effects, but also might not. Many lessons have had to be learned the hard way. You can’t test for effects you don’t know even exist. Remember the (first) Tacoma Narrows Bridge, the Hyatt Regency Walkway Collapse in Kansas City, and the failure of the railroad bridge that led to the formation of the Order of the Engineer.