Sometimes art is a metaphor and sometimes it is something else.


Clean Language’s pedigree is from psychotherapy and has found a home in coaching. It is also a valuable tool for discovering information about work products. As product managers, product owners, and stakeholders interact with the world and then describe a set of wants and needs they use metaphors. Metaphors are communication shortcuts that need to be explored. For example, product visions are often metaphor magnets. Most vision statements are considered internal and proprietary, therefore, they are hard to find (NDAs keep me from sharing the ones from companies I work with). Apple’s vision statement, according to Mission Statement Academy, is “We believe that we are on the face of the earth to make great products and that’s not changing.” If that statement was an input for building a product backlog there are several metaphors that would need to be explored so they can be converted into features and user stories. Clean Language is a way to get people to realize and describe what they know, what they think, how they feel while reducing bias in the results. Using clean language to identify and record requirements and needs follows the standard format for asking clean language questions with a few twists. (more…)

Large switch

Requirements are more than just on or off!

The Kano Model is a tool to help categorize product requirements.  The model created by Professor Kano groups all requirements into five categories:

  1. Must-be Quality, also known as basic needs,
  2. One-dimensional Quality, also known as performance attributes,
  3. Attractive Quality, also known as delighters,
  4. Indifferent Quality (neither improve or detract from satisfaction), and
  5. Reverse Quality (reduce satisfaction when achieved).

Most typical implementations of the Kano model tend to focus on the first three areas.   (more…)

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

The Software Process and Measurement Cast 411 includes four columns!  The first is our thoughts on servant leadership. A servant leader facilitates collaboration not only by creating a learning environment but also by helping the team to establish a vision and goals.  Servant leadership is a powerful tool to unlock the ability of teams or groups to deliver value. Many of the links between servant leadership and Agile are because servant leadership enables several of the principles in the Agile Manifesto, but servant leadership doesn’t work in every scenario. This essay will explore the origins of servant leadership, its ties with Agile and when to apply a servant leadership approach.

Jon Quigley anchors the cast with the second installment in a three-part arc on requirements in his  “The Alpha-Omega of Product Development” column. This week Jon discusses managing requirements.

Gene Hughson brings his Form Follows Function blog to the Software Process and Measurement Cast.  In this visit, Gene discusses his recent blog entry titled, “Organizations as Systems – “Uneasy Lies the Head that Wears the Crown”.  Gene points out that software development organizations live in a complex world where single factor explanations are dangerous.

Kim Pries, the Software Sensi, brings a great discussion of the concept of craftsmanship in software development to the Cast.  Craftsmanship and quality are related, but craftsmanship is a more intimate and personal attribute. (more…)

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

Special Note – SPAMCAST 409 was due to be posted last week, but bad things happened to my main computer and my backup decided to air-gap itself from the Internet.  That said, #409 is going up a week later so the Re-read Saturday news is a week out of date.  This week we talk about Chapters 22 and 23. I have declared that last weekend was a very stressful vacation from posting.  Now the show goes on!

In Software Process and Measurement Cast 409, we feature our essay on advice I recently provided to a listener to the podcast on whether a team is really one or two teams.  While the essay is a result of answering a friend’s question, the ideas in the essay can be applied when you are building any sort of team.

Our second column this week features a visit to Jeremy Berriault’s QA Corner.  Jeremy and I discussed how QA should communicate with other leaders in the organization.  In the third and final column, Jon M. Quigley begins a three-part arc on requirements in “The Alpha-Omega of Product Development.” This week on discusses the elicitation of requirements.

Re-Read Saturday News

This week we continue our re-read of Kent Beck’s XP Explained, Second Edition with a discussion of Chapters 20 and 21.  Chapter 20 is a discussion of applying XP.  The short version is that there is no one perfect way to apply XP, which dovetails nicely with Chapter 21 which addresses the concept of purity and certification.  IF there is no one perfect way to apply XP, how can there be an absolute litmus test for XP purity?   

Use the link to XP Explained in the show notes when you buy your copy to read along to support both the blog and podcast. Visit the Software Process and Measurement Blog ( to catch up on past installments of Re-Read Saturday.

Next we are going to read The Five Dysfunctions of a Team.  This will be a new book for me, therefore an initial read, not a re-read!  Steven Adams suggested the book and it has been on my list for a few years. Click the link (The Five Dysfunctions of a Team), buy a copy, and in a few weeks we will begin to read the book together.


In the next Software Process and Measurement Cast, we will feature our interview of Jessica Long.  Jessica and I discussed storytelling.  Storytelling is useful in all types of organizations for both projects and as a tool in organizational transformations.  

Jessica and I will both be presenting on using stories at the Agile Philly, Agile Tour 2016 on October 10th.  If you are in the Philadelphia area please register and attend!  

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.

Stories help you visualize your goals

Stories help you visualize your goals

In the Harvard Business Review article, The Irresistible Power of Storytelling as a Strategic Business Tool by Harrison Monarth (March 11, 2014), Keith Quesenberry notes:

People are attracted to stories because we’re social creatures and we relate to other people.

The power of storytelling is that it helps us understand each other and develop empathy. Storytelling is a tool that is useful for presentations, but also to help people frame their thoughts and for gathering information. A story provides both a deeper and more nuanced connection with information than most lists of PowerPoint bullets or even structured requirements documents. Here are just a few scenarios (other than presentations) where stories can be useful: (more…)

Listen Now

Subscribe on iTunes

Software Process and Measurement Cast 342 features our interview with Ellen Gottesdiener and Mary Gorman.  We discussed their great book, Discover to Deliver: Agile Product Planning and Analysis, requirements and Agile.  Ellen and Mary provided penetrating insight into how to work with requirements in an Agile environment, from discovery to delivery and beyond.

This is the second time Ellen, Mary and I talked Agile requirements.  After listening to this interview turn back the hands of time and listen to SPaMCAST 200.

Ellen Gottesdiener is an internationally recognized leader in the convergence of agile + requirements + product management + project management. She is founder and principal of EBG Consulting, which helps organizations adapt how they collaborate to improve business outcomes.

Ellen’s passion is helping people use modern product requirements practices to build valued products and great teams. She provides coaching, training, and facilitates discovery and planning workshops across diverse industries. Ellen is a world-renowned writer, speaker, and presenter. Her most recent book, co-authored with Mary Gorman, is Discover to Deliver: Agile Product Planning and Analysis. Ellen is author of two other acclaimed books: Requirements by Collaboration and The Software Requirements Memory Jogger.

Here’s where you digitally connect with Ellen: Blog | Twitter | Newsletter | LinkedIn

Mary Gorman, a leader in business analysis and requirements, is Vice President of Quality & Delivery at EBG Consulting. Mary coaches product teams, facilitates discovery workshops, and trains stakeholders in collaborative practices essential for defining high-value products. She speaks and writes for the agile, business analysis, and project management communities. Mary is co-author with Ellen Gottesdiener of Discover to Deliver: Agile Product Planning and Analysis.   

A Certified Business Analysis Professional, Mary helped develop the IIBA®’s A Guide to the Business Analysis Body of Knowledge® and certification exam. She also served on the task force that created the PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline. You can reach Mary via: Twitter | LinkedIn

Call to action!

Reviews of the podcast help to attract new listeners.  Can you write a review of the Software Process and Measurement Cast and post it on the podcatcher of your choice?  Whether you listen on ITunes or any other podcatcher, a review will help to grow the podcast!  Thank you in advance!

Re-Read Saturday News

The Re-Read Saturday focus on Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement began on February 21nd. The Goal has been hugely influential because it introduced the Theory of Constraints, which is central to lean thinking. The book is written as a business novel. Visit the Software Process and Measurement Blog and catch up on the re-read.

Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast.

Dead Tree Version or Kindle Version 

Next up on Re-Read Saturday: The Mythical Man-Month

Get a copy now and start reading!

Upcoming Events

June 9 – 12
San Diego, California
I will be speaking on June 10.  My presnetaiton is titled “Agile Estimation Using Functional Metrics.”

Let me know if you are attending!

Also upcoming conferences I will be involved in include and SQTM in September, BIFPUG in November. More on these great conferences next week.

Next SPaMCast

The next Software Process and Measurement Cast will feature our essay on Commitment, Part 2. Is commitment anti-Agile?  We think not!  Commitment is a core behavior for effective Agile!

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

Time for new shoes?

Time for new shoes?

I recently picked up a guide to a large conference that included a set of personas to help attendees decide which tracks would be of interest to them. The goal for the conference organizers was never the set of personas, but the guidance they provided to the attendees. The path from persona to the end goal in software development and maintenance often runs from persona to scenario then to user story.   Once a set of personas are established, the next step in the flow is to generate a set of scenarios. A scenario is a narrative that delineates purpose-driven interactions between a persona(s) and the product or system. Most projects require multiple scenarios to describe functionality that needs to be delivered.  An example of a very simple scenario follows:

As Tim Trackman completed his daily 10k, he found that the eyelet on his favorite running shoes had broken. He decided to order a new pair of the same shoes  so that he could continue training for his next half-marathon on his phone while he drank a cup of coffee in the hotel lobby.

The scenario includes a persona, rationale for the goal-driven behavior and the context in which the behavior will be accomplished. Unpacking the example:
Persona:  Tim Trackman
Goal-driven behavior: “order a new pair of the same shoes  so that he could continue training for his next half-marathon”
Context: “on his phone while he drank a cup of coffee in the hotel lobby”

Several other scenarios could be driven out of the same basic context, for example would Tim’s behavior be different if his favorite shoe style was not available? As with personas, a simple process flow provides a disciplined approach to generating scenarios.

  1. Familiarize the team with the goal of the product or system and the previously defined personas. This step sets the context for developing the persona. Typically the context is delivered by the product owner or someone from product management.
  2. Develop scenarios of the personas using the product or system. The scenarios are stories that explain how the persona interacts with system, their motivation and the how the interaction affects them.  I typically recommend using small sub-teams such as the Three Amigos to initially generate scenarios. In larger projects that will have multiple teams, I break the group into subgroups. The facilitator should use the context from step one to get the team to generate scenarios that fit the context.

    Remember when to write each scenario from the point of view of a specific persona. Stay away from glittering generalities. For example, if a story is written in which a persona sometimes does action, press the team to define the reason. The team must explore the motivation of the persona that would make them perform the action. For example in our running shoe scenario, if the scenario includes “sometimes Mr. Trackman searches for a shoe” the facilitator would need to push to get the team to define what the motivation for the behavior might be. These will generally require either additional scenarios or user stories later in the process.

  3. Consolidate duplicate scenarios. Carefully consider nuances in behavior before declaring two scenarios as duplicates. Nuances can be variants in behaviors can require nuances in code.
  4. Build a scenario map. Lay the scenarios out as an activity flow. Actions should flow from left to right. In our shoe scenario, Tim would buy shoes and then later get the shoes and perhaps even later return the shoes. Scenarios that involve the primary persona should be on the top row of the map (this can be used to define the minimum viable product) and tertiary personas at the bottom.
  5. Review the scenarios. Review the scenarios with the team(s). Use the review process to validate the scenarios and fill in gaps. The review process will generate conversation that can be used to add details to the scenarios. In larger projects the review process can be done as a single group (difficult to arrange) or through a number of reviews with smaller teams. The later will require a step to integrate all of the comments and feedback into the scenarios.

Coming back to our Logo Pint Glass example, a typical scenario for the “Brewdog would be:

When visiting a microbrewery, Tom “Brewdog” Pinternick, notices that there are logo pint glasses on sale. The brewpub has several varieties. Tom can’t remember if he has collected all of the different glasses being offered. Recognizing a potential buying opportunity, Tom opens the Logo Pint Glass app and browses the glasses he has already collected for this brewpub and discovers one the glasses is new.

In part 3 we will generate a set of user stories from our scenarios.

Logo Glass Entry Screen

Personas are a tool to develop an understanding of a user’s needs. There are a number of ways personas can be used as teams develop and deliver value. The well-trodden path between personas and value is through user stories. The most effective way to navigate that path from personas to stories is using scenarios as a stepping stone. In the following two essays we will walk through a process to create personas, scenarios and user stories using the example of a beer glass logging app we have used in the past to describe Agile testing. The example is not meant to be complete, but rather to illustrate of the process the path form personas to user stories can take.

Generating Personas

Many articles on using personas to generate user stories begin with a step that is very close to saying, “get some personas.” When Alan Cooper introduced personas as archetypical users of the product or system being developed, he indicated that personas were to be generated based on research done on target or audience of the product. Unfortunately with out guidance on how to create a persona the idea of doing research has gotten lost. What most people need is a lean process for developing personas. A simple process flow to develop personas is as follows:

  1. Brainstorm an initial set of potential personas
  2. Gather data through research and interviews
  3. Refine list of potential personas
  4. Create the initial persona profiles (use template)
  5. Review, sort and prioritize personas
  6. Finalize (-ish) personas
  7. Post or share personas

Step 1 Gather a cross section of the parties impacted by the system or product. For small teams I generally recommend using the Three Amigos (product owner, lead technical and lead testing personnel), while in larger projects with multiple teams the group tends to grow to include product owners and leads from each team. Use one standard brainstorming technique to generate an initial set of personas. This list will be refined as the process progresses. Common seed questions for the brainstorming session include:

  1. What type of people will use this product or system?
  2. How will this product or system be used?

The goal of the session is to generate an initial list of persona names; however these sessions typically expose a huge amount of information. Write everything down; it will be useful later. The list of personas will not be perfect, nor will it be complete. Do not be concerned as the process uses a review and refinement process to ensure the end product is solid.

Step 2 Gather background information using the initial set of personas as a guide. Research can take many forms, including behavioral surveys, interviews and accumulated team knowledge. If you are going to use surveys to collect data to enhance your persona and you going use the data for product decisions, hire a market research firm or organizational psychologist to construct and execute the survey. The most common technique for internal IT projects is interviews. The technique is fairly easy, cheap and generally effective. I recommend creating a formal set of questions before beginning the interview process. The goal of all of the research techniques is for the team to develop a deeper understanding of users and how they will interact with the system.

Step 3 Refine the list of potential personas. Synthesize the original list with the research gathered in step 2 to update the list of personas. The consolidated list should weed out any personas that show substantial overlaps and expose gaps in the original list. In circumstances where the team does not know much about the system or product being built step 1 many not be possible until research is done therefore step 2 may be the entry point in the process.

Step 4 Create the initial personas by filling in the standard template we documented in Personas: Nuts and Bolts. I generally find that the process of completing the template continues the refinement process by identifying gaps and overlaps.

Step 5 Review the personas with the WHOLE team(s). Use this step to continue the refinement process and as a mechanism to add detail to the descriptions and behaviors documented in the template. Do not hesitate to add, change or delete personas at this stage. In larger projects with multiple teams begin by doing individual team reviews then consolidate the personas based on the input. The review process allows the team to share a broader perspective. A whole group review also creates a common vision of “who” the product or system is being built for.

During the review process prioritize the personas. Prioritization reflects the truth that not all personas are created equal, and some types of users are simply more important to satisfy. Prioritization provides the team with a mechanism to make decisions. Some of the personas represent critical stakeholders and others represent those that are less involved. Consider using a 3 level approach, with the top or primary persona being the most important to satisfy. The second level persona is important but not as important as the primary persona. I often find personas at this level provide direct support to the primary persona. The final category of personas is involved, but perhaps in a secondary support role. For example, a pilot would be a primary persona for an airline flight, the ground crew would be a secondary persona and the TSA agents would be a third-level role.

Step 6 Develop an agreement across the project that the personas that have been captured make sense and are as complete as they can be at this point. Always recognize that the personas can evolve and change. The act of generating a public agreement helps teams (or teams of teams) start on the same page.

Step 7 Post the personas on the team wall so that everyone can use them as a reference. In distributed teams post the personas on the wall in each team room and one the team’s homepage (Sharepoint, WIKI or any other tool being used).

Here is an example persona based on the Beer Logo Glass tracking application:

Persona Name: Tom “The Brewdog” Pinternick (primary persona)

Persona Name: Tom “The Brewdog” Pinternick (primary persona)

Job: Day job is QA manager, but at night he is a home brewer.

Goal: As a home brewer, Tom likes to visit microbreweries to get a broad exposure to different styles of beer. To mark visits to microbreweries, Tom buys logo pint glasses. Logo pint glasses can be expensive and it does not make sense to collect the same glass twice, therefore he needs to make sure he keeps track of the glasses he has purchased.

Personality: Brewing collectables, including pint glasses, is a badge of honor. Microbreweries without logo pint glasses are an anathema to the “Brew Dog.” A visit without evidence is a visit that never occurred (regardless of memories).

Lifestyle: Tom “The Brewdog” Pinternick lives with his foot on the accelerator, whether family or work, he tends to be single-minded. The balance between work, hobbies and family is important, but so is keeping score.

An archetypal user of dresses.

An archetypal user of dresses.

A persona represents an archetypical user that interacts with a system or product. Typically the first introduction a developer or product owner might have to the concept is when they are writing user stories in the form of <persona><goal><benefit>. If the concept of persona was just used in user stories they would be interesting, however personas have other uses. Other uses of personas include:

  1. Identifying requirements. Personas provide teams with a platform for developing scenarios that incorporate both who will use the system or product and how it will be used. Scenarios delineate purpose-driven interactions between a persona(s) and the product or system. The expectations, motivations and needs defined as part of a persona gives team members the information needed to playact solving problems as if they were an archetypical user. This allows the team to mirror real content and usage without tying the scenario to a specific system solution.
  2. Guiding decisions. As the development process moves from user story to delivered functionality, teams will make innumerable decisions. Personas help teams make better decisions by providing them with a tool to ground or justify a decision. I recently watched a team use a set of personas to make a decision about how they would structure a user survey. The team asked themselves how each persona would react to the design choice being considered. Several tweaks were adopted based on how the team felt the personas would react. The team in question keeps a copy of each persona on the wall in their team room and references the personas as a matter of course. A secondary impact of using a common set of personas to guide decisions is foe the team to align to the common goal of being user focused.
  3. Identifying releases.   While there are a wide variety of release strategies including continuous deployment and minimum viable products, teams and product owners often struggle with grouping functions and features for release. Personas can be used to identify which features and functions are related so that a release can used to solve a persona’s (or group of personas’) specific needs. I often use personas and the scenarios used to generate requirements to identify a minimum viable product.  Once a release candidate is identified I ask the team whether the group of functions being considered could be used by a specific persona and then whether the use would generate useful feedback. If the answer is yes for this part but no for another part, the release can be trimmed down to just the yes part. Alternately if the answer is no because we need something else, I generally start the campaign to increase the prioritization of that “something else.”
  4. Facilitating communication. All projects require well thought out communications. Personas provide the team with information needed to plan communications. Jo Ann Sweeney, author of the Explaining Change column on the Software Process and Measurement Cast strongly suggests that knowing your audience is a critical step in getting communications right (albeit she says it with a British accent). Personas are a tool to define your audience. The details of the persona’s needs, motivation and backstory provide a wealth of information needed to shape and develop a communication plan.

Personas are not just for user stories. Personas represent a lot of valuable information about who will use the system or product  the intrinsic benefit they expect. The information documented is useful across the entire development life cycle. A simple way of reminding a team that it really isn’t just about the system or product is to tape the personas to the project team room wall to create information radiators that remind the team that the users have an identity.

Actors playing different roles.

Actors playing different roles.

Classic requirements definition techniques, such as use cases, use roles and actors show interactions and movement of data between systems. An actor is defined as an entity that plays a specific role within a system. Conceptually, actors in systems and products are not very different from actors in a theater. In both cases, an actor can play one role in one situation and another role in another. For example, David Tennant played the role of Dr. Who and then later played the role of Alec Hardy in Broadchurch. An auto mechanic (actor) might play one role when using a piece of diagnostic software and quite a different role when entering your bill into the cash register. Actors play roles to accomplish some outcome which make them valuable for defining and documenting use cases. Actors are less useful if they are used for eliciting and documenting user stories.

Agile requirements (typically documented as user stories) use the concept of personas to identify interaction with an application or product. Personas and actors, though related concepts, are not the same and should not be used interchangeably. Use cases focus on defining a specific process and how that process will be accomplished in a step-by-step process. A user story defines an outcome, who needs the outcome and the benefit they will received. Actors and persona can be easily confused. When confused practitioners can easily fall into the habit of substituting actors for personas or vice versa, which reduces the effectiveness of which ever process is used.

Two related differences are helpful to understanding why actors and personas are very different. The first is definition granularity. Actors can be a person, group or external system, and are generally defined in very broad terms, either as a name or a short title tied to an explicit role. For example, I recently reviewed a use case for entering a purchase order that included actors for a “purchasing department clerk”, “general ledger system” and “accounting supervisor.” The purchasing clerk enters the purchase order, a feed sent to the general ledger and the accounting supervisor reviews the data entered. A persona represents one of the archetypical users that interacts with the system or product. Personas can play multiple roles depending on their current needs and motivation. A related difference is the documentation granularity in Personas: Nuts and Bolts we defined a template that included name, picture, motivation, backstory and needs. Persona are far more detailed and structured to connection between the team and the persona. Actors are typically defined as a title (note some methods add annotations however these never rise the level seen when defining a persona hence the occasional whining about persona being heavy weight).

Persona are used in user stories and generally are more robust than actors. A persona is designed to help the team understand who they are developing a system or product. The detail allows the team to “get into the archetypical users head” as user stories and functionality is developed. Actors are primarily used in use cases which are used as a tool to develop flow or process based requirements. Use cases are also often used to validate designs and as tool to drive testing activities. In these scenarios the focus is how the work will be performed and in what order rather than on why and what needs are being met. The way actors are used does not require the level of documentation to be effective.

Actors include far less detail than a persona and typically are identified at a significantly higher level of abstractions. Based on the higher level of abstraction of actors, many personas might be summarized into an actor. Both actors and personas have value however if you are using user stories, actors do not provide a deep enough understanding of the needs and motivations of the users and customers of the system. Alternately when using techniques like use cases, developing profiles archetypical users replete with their back story, needs, motivations and picture is overkill. I learned many years ago that the right tool for the right job makes the job easier.

Next Page »