The purpose of the single user story gets lost in the flow of work

As most Agile and Kanban teams know, user stories can help teams collaborate around bite-sized chunks of work. The single, trackable user story allows teams to measure and sustain a constant flow of work. And yet, I have noticed that as teams become more proficient at establishing a flow, the usefulness of the user story as a way to communicate customer value diminishes severely.

As Jeff Patton says in The new user story is a backlog map:

Arranging user stories in the order you’ll build them doesn’t help me explain to others what the system does. Try handing your user story backlog to your stakeholders or users when they ask you the question “what does the system you’re building do?”

At the top of the [backlog] map are “big stories.” I call them user activities (borrowing the term from UX people like Larry Constantine and Don Norman). An activity is sort of a big thing that people do – something that has lots of steps, and doesn’t always have a precise workflow.

On my teams we have taken the idea of applying activity-centered design to the backlog and extended it to the entire product development cycle; end-to-end and continuously.

Activity maps help you track progress toward delivering customer value

Activity maps are a simple and lightweight artifact that help you track progress toward delivering customer value. Through the creation of an activity map, your team will create a precise and elegant lexicon that will sharpen your understanding about what you are trying accomplish.

Activity Map: Activity, actions, and operations

• Activity: The most basic unit of analysis defined as any collaborative, goal-directed, and purposeful human endeavor
• Actions: Activities consist of a chain of actions that represent an immediate, specific, and conscious human goal
• Operations: Actions consist of a chain of operations that are habitual, automatic, and routinized

Simple, repeatable, and useful

Intentionally simple, activity maps may be re-purposed easily in digital and physical form. In ThoughtWorks’ Mingle, activity maps can be set up in a matter of minutes. With added power from Mingle’s query language “MQL” you can easily track the progress of individual user stories in the context of their corresponding operations.

Activity, actions, and operations in ThoughtWorks’ Mingle

Tracking user story progress in the context of an operation using ThoughtWorks’ Mingle

Don’t make people do the grunt work

In activity theory, the operation is the smallest unit of analysis of an activity. Any analysis beyond the operational level will put you squarely in the realm of making people do grunt work, negating any intention of using technology to improve people’s lives.

My favorite example of how technology can remove menial work from our daily lives is the GPS feature found in Apple and Google’s map applications. When you want directions to a destination from your current location, you don’t have to know anything about your current location: No physical address. Nothing. It just works.

How do I get started making activity maps?

The best place to start is with your customers. Talk to as many as you can and as often as you can. It also helps to first understand your customer’s perspective through the lens of an activity system.

How do I know if I am doing it right?

It comes down to creating an elegant and precise language about the activity your product supports. For the activity, keep it high level yet meaningful. Remember, an activity is a purposeful human endeavor that is inherently social and outcome-focused.

Examples of activities:

• Following people and conversations (with Twitter)
• Keeping up with friends (with Facebook)
• Photo sharing (with Instagram)

For actions and operations, avoid using terms like manage, create, document, and user. Instead, combine meaningful verbs and nouns such as “get directions”, “invite friends”, and “take a picture”.

Further Reading

• The new user story backlog is a map
• Activity Theory: Basic Concepts and Applications
• Story Mapper by Carbon Five

Just about every conversation we have on ThoughtWork Studios teams revolve around two questions: “How might we encourage and enable team collaboration?” and “How might we enable teams to focus on customer value?” We also filter all of our decisions through a clear and precise language about the activity a product supports. These questions and the precise language about the activity add up to the single most important question: Who do we want our customers to become?

Henry Ford didn’t just facilitate “mass production;” he enabled the human capital of “driving.” George Eastman didn’t just create cheap new cameras and films; he created photographers. Sam Walton’s Walmart successfully deployed scale, satellites and supply chain superiority that turned shoppers into higher volume, one-stop everyday low-pricing customers. Steve Jobs didn’t merely “reinvent” personal computing and mobile telephony; he reinvented how people physically touched, stroked, bumped and talked with their technologies. Google’s core technology breakthrough may appear to be “search;” but the company’s algorithms and business model is contingent upon creating hundreds of millions of smart “searchers” worldwide.—Michael Schrage

So, I am asking you this question: Who do you want your customers to become?

“How often we neglect to address the purposes of those who are in the system and those of the environment.”—Béla Bánáthy

“No man is an island,
Entire of itself.
Each is a piece of the continent,
A part of the main.”—John Donne

Design for Activities, Not Individuals

Most products support activities underpinned by collaboration and sharing. Designing for individuals may actually be harmful because these activities reflect ongoing transformations of artifacts, individuals, and social interactions. Focusing on individuals might improve things for one person at the cost of others. As Donald Norman says in Human-Centered Design Considered Harmful:

The more something is tailored for the particular likes, dislikes, skills, and needs of a particular target population, the less likely it will be appropriate for others.

Activity-Centered Design (ACD) focuses on the activity context in which individuals interact with your product. Instead of analyzing specific goals and tasks, ACD focuses on the analysis of meaningful, goal-directed actions supported by tools and artifacts in a social world. The Wikipedia article about Activity Theory says:

The goal of Activity Theory is understanding the mental capabilities of a single individual. However, it rejects the isolated individuals as insufficient unit of analysis, analyzing the cultural and technical aspects of human actions.

Limitations of Personas

Persona documents have become the de facto design artifact for human-centered design. Personas are a proxy for a real customer when teams lack customer participation. Don’t get me wrong, I understand the value of personas as a way to build empathy for customers. A designer will typically create a persona document to bring a human perspective to the conversation. Sometimes, this is a callow reaction to a team overly focused on technical implementation. Most of the time, the persona document contains inert data. Through the process of modeling the ultimate customer, the persona becomes too general to represent any real-life customer.

Personas Increase Risk of Feature Bloat

Many companies boast about their human-centered approach to design and their use of personas, yet they still manage to design complicated products characterized by bloat, infrequent improvements, and a set of features that no single customer fully utilizes. A product team that bootstraps their design process by identifying several individual personas doom themselves to create a bloated product. Obliged to partition the solution across a set of features for each persona, this approach results in an incoherent product difficult for people to adopt and use in their daily lives.

I believe persona documents emerge for several common reasons:

• The customer is missing or does not actually exist
• A preference for analyzing personas through the myopia of roles, job titles, and demographics
• Unreasonable paranoia about engineers making decisions without empathy for customers

I am not saying that personas are “bad” and that we should ignore decades of progress in human-centered design thinking. On the contrary, I believe products which metastasize with limited focus on real human needs can improve with human-centered methods like persona documents.

Activity Systems: Participants and Activities

An activity system is a community of people interacting with each other through tools and artifacts in the social world. As Béla Bánáthy says in Characteristics of A Human Activity System:

Purpose, process, interaction, integration, and emergence are salient markers of understanding … we should think about and define human activity systems always at three levels: (1) A system serves the purpose of its collective entity. (2) It serves the purpose of its members. (3) It serves its environment of the larger system in which it is embedded.

The people in the system are affected by being in the system, and by their participation in the system they affect the system. People in the system select and carry out activities—individually and collectively—that will enable them to attain a collectively identified purpose.

The process by which these relationships are maintained is the system’s regulation—the rules of the game—and the limits within which these rules can be sustained are the conditions of the systems stability through time. It is here where commitment (to shared purpose) and motivation (to carry out activities) play such an important role.

People are affected by their participation in the activity system, and through their participation they affect the activity system.

Instead of analyzing individuals as personas, you can analyze from an activity perspective using a human activity diagram. I typically create a human activity diagram in collaboration with my team so we can quickly develop a shared understanding of the new activity context we are working in. The diagram’s simplicity makes it easy to share, redraw on a whiteboard, and easily transform as you learn more about the activity. Professor Yrjö Engeström from the University of Helsinki in Finland invented the human activity system diagram to facilitate his own research into organizational and workplace learning.

HUMAN ACTIVITY DIAGRAM

I recommend redrawing this diagram and filling it in with an activity context familiar to you. Then, try filling in another one with an activity context less familiar to you. Many questions will arrive in your head as you try to fill it in. Your questions will become hypotheses to validate by talking with people and immersing yourself in their activity context.

From left to right the eight categories are:

• Participants: Actors engaging in the activity
• Rules and Rituals: Conventions and guidelines regulating the activity
• Community: Social context shared by all participants engaging in the activity
• Activity: Any purposeful human endeavor
• Tools and Artifacts: The means for the accumulation and transmission of social knowledge in the activity
• Division of Labor: Social strata and hierarchical structure of the activity
• Objective: A shared goal obtained through the interaction between participants, tools, and artifacts within the context of the activity
• Outcomes: The participant’s motivations for obtaining the objective

CASUAL CARPOOL – HUMAN ACTIVITY DIAGRAM

As a resident of Berkeley and an employee at a company based in the financial district of San Francisco, I am very familiar with the activity of casual carpool. As a new casual carpooler, I started brainstorming ideas for a product to solve two problems I observed: A long queue of passengers, and a long queue of drivers at peak times (from 8 – 9:00 AM). I assumed an imbalance in either queue was an indication of impeded flow: A problem to fix. I immediately envisioned app ideas that I was certain no one would willingly adopt; certainly not in the morning and not when they’re in a hurry to get to work.

Instead of wasting my time throwing a solution at the problem, I opted to improve my understanding of the activity by looking at the casual carpool as an activity system. As I observed the rules and rituals of casual carpooling and the behavior patterns that the participants displayed, I realized that the queues actually worked fine. Any imbalance between the flow of the passenger queue and the driver queue were fleeting; average wait times were well under 10 minutes.

By analyzing the whole system, rather than individuals, I came to the realization that the objective for drivers and passengers to carpool with minimal coordination was already happening. In the casual carpool pickup spots rituals and norms naturally emerge with readily available tools and artifacts. Namely, vehicles and queues. What about other issues like lost-and-found items? The system has already compensated: If someone forgets to take a purse or a phone when they get out of a vehicle, the driver can simply post “found” signs at the head of the passenger queue. Any other solution I can think of would require another layer of coordination between drivers and passengers.

Casual Carpool represents an emergent system influenced by external forces such as state laws and our disdain for congestion on roadways. Any solution in the form of a tool like an iPhone app or even a human agent like a “Carpool Coordinator” would undermine the overall objective of “carpool with minimal coordination”.

In the next example you will see how you can use a human activity diagram to generate an entirely new tool in an emerging activity system context.

What are we making?

At ThoughtWorks Studios I work with teams who create products used in software development environments. I often help these teams develop narratives that frame product decisions from a customer perspective. In order to develop these narratives, the depth of understanding of the human activity context must be deep, and the customer’s language common to the team.

One of these teams, Luau, provide a measurable way for customers to improve their software development processes through evidence-based experimentation. In the past, when I would ask the team “Why is your product important?” I got slightly different answers from each of them. The common term they would use was “cycle time”. Cycle time is the measure of the amount of time it takes for an idea to go from doing to done. The team was certain cycle time was important to their customers, and it was their job to make a tool to convince customers it was the right measure for process improvement.

The team had to figure out how they would present cycle time to their customers, and how their customers would define their workflows. The Luau team also had to figure out a solution which would integrate with their customer’s daily lives. To help them discover possible solutions I used Engeström’s human activity diagram. I introduced the diagram in a workshop setting and encouraged them to try to answer the following questions:

• What is the activity that your product will support?
• Who are the participants in the activity?
• What objectives do participants achieve through this activity?
• What are the tools and artifacts these participants already use in their daily lives that are relevant to this activity?
• What are the outcomes of this activity?

The product team members had about five minutes to fill in Engeström’s diagram. Then, they each took turns presenting their diagram and receiving feedback from each other about their assumptions. Within the first thirty minutes of the workshop, I witnessed a common language develop about the activity their cycle time product would support. In turn, a new set of hypotheses formed that they could go out and validate.

You can see the result of the workshop in the diagram below. They actually displayed it in their team space and referred to it whenever they were vetting ideas for features or formulating questions they would ask during interviews with customers.

SOFTWARE PROCESS IMPROVEMENT – HUMAN ACTIVITY DIAGRAM

What are they making now? A product that helps teams continuously improve by providing visibility into the health of the team. Using indicators like cycle time, the product helps teams identify work that is slow, stuck, or churning, and potential bottlenecks in the workflow. Their customers already rely on information radiators for continuous visibility into the health of their projects, so the product team’s product works as an information radiator. The product “radiates” in a team room on a LCD display, providing customers with the ability to drill down and see which of their work items are slow, stuck, churning, or a potential bottleneck.

As an aside, the team found that the activity diagram and the business model canvas converged in interesting ways. As they performed customer development activities, they kept the “Software Process Improvement” activity diagram in the back of their mind. The activity informed the top-level goal for their product (help customers who want to continuously improve) while the business model canvas reflected how they would garner customer attention, acquire customers, and retain customers for their solution.

Can you think of other examples about how activity systems have affected product decisions?

Further Reading

Donald Norman shares his thoughts about Activity-Centered Design in these articles:

• Logic Versus Usage: The Case for Activity-Centered Design
• Human-Centered Design Considered Harmful
• HCD harmful? A Clarification

Also, anthropology professor Bonnie Nardi has written a book called Acting with Technology that explores activity theory as a framework for interaction design. Bonnie and Donald were once colleagues at Apple.