IMG_1249

Part of the reason I embarked on Re-Read Saturdays was to refresh myself on a number of books that have had significant impact on my career. Re-grounding myself was somwhat of a selfish idea; however at the same time as I refreshing myself on important concepts Re-read Saturday has provided a platform to share those ideas with a wider audience. As we begin the second half of the re-read of The Goal, I have been struck how many people have been exposed to the ideas in The Goal and how many of those ideas they have put into action, even if they can’t recite the Theory of Constraints verbatim. For example, the development and test manager that recognizing the handoff from development to test as a bottleneck and worked out a priorization scheme that maximized throughput of critical projects. Earlier entries in this re-read are:

Part 1       Part 2       Part 3      Part 4      Part 5      Part 6      Part 7      Part 8

Chapter 23: Alex meets with Ted Spencer, the supervisor for the heat-treat area, who is asking Alex to get the “computer guy” (Ralph) off his back. Ralph is asking Ted to keep significantly better records of when parts enter and exit the heat-treat process. Ted indicates that he does not know why Ralph wants the data. In the past few chapters we have seen the power of transparency and communication to support process changes; in this scenario the lack of transparency has generated conflict. When Alex meets with Ralph he finds that has been trying to use the process data to understand why more shipments have not been being completed, and has noticed SIGNIFICANT variability in the times that parts enter and exit the heat-treat process. Often parts that have been completed sit until someone has time to unload the furnace. This originally lead him to question the validity of the data, so he requested that Ted to generate better data. The issue turns out to be that parts are often not immediately unloaded after the heat-treat process due to timing and staffing issues. The furnace is loaded and then heats the parts for four or five hours before being ready to be unloaded. In order to maximize efficiency, people are assigned other jobs during the heating process, which causes the timing and resource contention problems. The heat-treat bottleneck is not being run at or near maximum capacity, which reduces the output of the plant. As Ralph leaves he mentions that he believes they can predict when orders ship based on the bottlenecks (this is a bit of foreshadowing; however an area of further reading you might consider is our discussion of Little’s Law). Note that the problem with the heat-treat process was identified through measurement and analysis of the data. The problem Ralph identified is a reflection of the ripple effect of other changes and that as the process is refined better information is exposed.

Alex and Rob Donavon, the production supervisor, meet (loudly) over the discovery that the heat-treat process is not being used to maximum capacity. The discussion unearths that similar timing and resource problems are happening at the NCX-10, even though the new work rules ensure that no breaks are taken during machine set-up. The problem occurs when the machine stops and before the set-up begins again. They decide to staff both bottlenecks 24×7 so there is no downtime. The problem of who to staff the NCX-10 and heat-treat with immediately exposes a new set of constraints, this time as a reflection of the overall organization’s policies on pay and hiring. Hiring, including layoff callbacks, are currently frozen, therefore Alex and his team need to rob Peter to pay Paul. (A bit of foreshadowing – the impact of change can ripple through other process steps.)   In an overall sense, the efficiency of both the heat-treat and NCX-10 steps as measured in terms of cost per unit is being reduced while the overall effectiveness of the plant is being increased by the changes being made.

One of the other steps taken as part of the new changes to staff the bottlenecks is that Alex has let the foremen in the heat-treat area know that they will be rewarded for changes that improve the output of the process. The third-shift foreman makes two process changes that have a significant impact. He has broken high priority orders down and batched parts that require the same treatment together, and has prepped the material so that it is staged to be loaded as soon as the furnace is ready. He also points out to Alex that with a little help from engineering they can modify the loading process so that parts can be wheeled in and wheeled out rather than lifted in an out by a crane. The foreman is immediately shifted to first shift to work with engineering to make the changes and document the process. In Agile frameworks like Scrum this is EXACTLY why the teams doing the work need to reflect on how they are doing the work and take steps to improve their processes.

Chapter 24 begins on an up note! The plant has been able to ship more orders with a higher sales value than ever before, while reducing the level of work-in-progress. Champagne flows! During the celebration Bill Peach (Alex’s boss) calls and delivers praise from one the clients that has noticed that his orders are getting delivered. In light of the continuing celebration Alex is driven home by a female member of staff, which leads to complications with Julie, his estranged wife, who just happens to be waiting to surprise Alex. If Alex’s marriage problems were not enough, the next workday Alex discovers that like a virus, the bottlenecks have spread. Changes to the process to focus on making the parts that flow through the bottleneck more available have caused process steps for other parts to become bottlenecks.

Alex tracks down Johan and briefs him on what they have done. Johan suggests a visit to see what has been accomplished.

The Goal is truly about the Theory of Constraints; however Johan’s role is the same as an Agile coach. Johan rarely solves the plants problems directly, but rather asks the questions that lead to a solution. The Goal provides a great side benefit of reinforcing one the central ideas of Agile coaching.

Summary of The Goal so far:

Chapters 1 through 3 actively present the reader with a burning platform. The plant and division are failing. Alex Rogo has actively pursued increased efficiency and automation to generate cost reductions, however performance is falling even further behind and fear has become central feature in the corporate culture.

Chapters 4 through 6 shift the focus from steps in the process to the process as a whole. Chapters 4 – 6 move us down the path of identifying the ultimate goal of the organization (in this book). The goal is making money and embracing the big picture of systems thinking. In this section, the authors point out that we are often caught up with pursuing interim goals, such as quality, efficiency or even employment, to the exclusion of the of the ultimate goal. We are reminded by the burning platform identified in the first few pages of the book, the impending closure of the plant and perhaps the division, which in the long run an organization must make progress towards their ultimate goal, or they won’t exist.

Chapters 7 through 9 show Alex’s commitment to change, seeks more precise advice from Johan, brings his closest reports into the discussion and begins a dialog with his wife (remember this is a novel). In this section of the book the concept “that you get what you measure” is addressed. In this section of the book, we see measures of efficiency being used at the level of part production, but not at the level of whole orders or even sales. We discover the corollary to the adage ‘you get what you measure’ is that if you measure the wrong thing …you get the wrong thing. We begin to see Alex’s urgency and commitment to make a change.

Chapters 10 through 12 mark a turning point in the book. Alex has embraced a more systems view of the plant and that the measures that have been used to date are more focused on optimizing parts of the process to the detriment to overall goal of the plant.  What has not fallen into place is how to take that new knowledge and change how the plant works. The introduction of the concepts of dependent events and statistical variation begin the shift the conceptual understanding of what measure towards how the management team can actually use that information.

Chapters 13 through 16 drive home the point that dependent events and statistical variation impact the performance of the overall system. In order for the overall process to be more effective you have to understand the capability and capacity of each step and then take a systems view. These chapters establish the concepts of bottlenecks and constraints without directly naming them and that focusing on local optimums causes more trouble than benefit.

Chapters 17 through 18 introduces the concept of bottlenecked resources. The affect of the combination dependent events and statistical variability through bottlenecked resources makes delivery unpredictable and substantially more costly. The variability in flow through the process exposes bottlenecks that limit our ability to catch up, making projects and products late or worse generating technical debt when corners are cut in order to make the date or budget.

Chapters 19 through 20 begins with Johan coaching Alex’s team to help them to identify a pallet of possible solutions. They discover that every time the capacity of a bottleneck is increased more product can be shipped.  Changing the capacity of a bottleneck includes reducing down time and the amount of waste the process generates. The impact of a bottleneck is not the cost of individual part, but the cost of the whole product that cannot be shipped. Instead of waiting to make all of the changes Alex and his team implement changes incrementally rather than waiting until they can deliver all of the changes.

Chapters 21 through 22 are a short primer on change management. Just telling people to do something different does not generate support. Significant change requires transparency, communication and involvement. One of Deming’s 14 Principles is constancy of purpose. Alex and his team engage the workforce though a wide range of communication tools and while staying focused on implementing the changes needed to stay in business.

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

 

2751403120_ae8be53206_b

#NoEstimates is a lightening rod.

 

Estimation is one of the lightening rod issues in software development and maintenance. Over the past few years the concept of #NoEstimates has emerged and has become a movement within the Agile community. Due to its newness, #NoEstimates has several camps revolving around a central concept. This essay begins the process of identifying and defining a core set of concepts in order to have a measured discussion.  A  shared language accross the gamut of estimating ideas whether Agile or not including #NoEstimates is critical for comparing both sets of concepts.  We begin our exploration of the ideas around the #NoEstimates concepts by establishing a context that includes classic estimatimation and #NoEstimates.

Classic Estimation Context: Estimation as a topic is often a synthesis of three related, but different concepts. The three concepts are budgeting, estimation and planning. Becasue these three conccepts are often conflated it is important to understand tthe relationship between the three.  These are typical in a normal commercial organization, however these concepts might be called different things depending your business model. An estimate is a finite approximation of cost, effort and/or duration based on some basis of knowledge (this is known as a basis of estimation). The flow of activity conflated as estimation often runs from budget, to project estimation to planning. In most organizations, the act of generating a finite approximation typically begins as a form of portfolio management in order to generate a budget for a department or group. The budgeting process helps make decisions about which pieces of work are to be done. Most organizations have a portfolio of work that is larger than they can accomplish, therefore they need a mechanism to prioritize. Most portfolio managers, whether proponents of an Agile or a classic approach, would defend using value as a key determinant of prioritization. Value requires having some type of forecast of cost and benefit of the project over some timeframe. Once a project enters a pipeline in a classic organization. an estimate is typically generated.  The estimate is generally believed to be more accurate than the orgianal  budget due to the information gathered as the project is groomed to begin. Plans breakdown stories into tasks often with personal assigned, an estimate of effort generated at the task level and sum the estimates into higher-level estimates. Any of these steps can (but should not) be called estimation. The three -level process described above, if misused, can cause several team and organizational issues. Proponents of the #NoEstimates movement often classify these issues as estimation pathologies; we will explore these “pathologies” in later essays.

#NoEstimates Context:  There are two camps macro camps in the #NoEstimate movement (the two camps probably reflect more of continuum of ideas rathe than absolutes).  The first camp argues that a team should break work down into small chunks and then immediately begin completing those small chunks (doing the highest value first). The chunks would build up quickly to a minimum viable product (MVP) that can generate feedback, so the team can hone its ability to deliver value. I call this camp the “Feedback’ers”, and luminaries like Woody Zuill often champion this camp. A second camp begins in a similar manner – by breaking the work into small pieces, prioritizing on value (and perhaps risk), delivering against a MVP to generate feedback – but they measure throughput. Throughput is a measure of how many units of work (e.g. stories or widgets) a team can deliver in a specific period of time. Continuously measuring the throughput of the team provides a tool to understand when work needs to start in order for to be delivered within a period time. Average throughput is used to provide the team and other stakeholders with a forecast of the future. This is very similar to throughput measured used in Kanban. People like Vasco Duarte (listen to my interview with Vasco) champion the second camp, which I tend to call the “Kanban’ers”.  I recently heard David Anderson, the Kanban visionary, discuss a similar #NoEstimates position using throughput as a forecasting tool. Both camps in the #NoEstimates movement eschew developing story- or task-level estimates. The major difference is on the use of throughput to provide forecasting which is central to bottom-up estimating and planning at the lowest level of the classic estimation continuum.

When done correctly, both #NoEstimates and classic estimation are tools to generate feedback and create guidance for the organization. In its purest form #NoEstimates uses functionality to generate feedback and to provide guidance about what is possible. The less absolutist “Kanban’er” form of #NoEstimates uses both functional software and throughput measures as feedback and guidance tools. Classic estimation tools use plans and performance to the plan to generate feedback and guidance. The goal is usually the same, it is just that the mechanisms are very different. With an established context and vocabulary exlore the concepts more deeply.

Tom “The Brewdog” Pinternick

Tom “The Brewdog” Pinternick

The goal of all software centric projects is functional software that meets user needs and provides value. The often-trod path to functional software begins at a group of personas, then to scenarios and then to user stories before being translated into software or other technical requirements.

Personas: A persona represents one of the archetypical users that interacts with the system or product.

Scenarios: A scenario is a narrative that describes purpose-driven interactions between a persona(s) and the product or system.

User Stories: A user story is a brief, simple requirement statement from the user perspective.

In Personas, Scenarios and Stories, Part 2 we generated a simple scenario for the “Brewdog” Logo Glass Collection Application:

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.

After a team accepts the narrative story contained in a scenario the team needs to mine the scenario for user stories. The typical format for a user story is <persona> <goal> <benefit>. Using the scenario above, the first user story that can be generated is:

Tom “Brewdog” Pinternick wants to browse his glass collection so that he does not buy the same glass twice.

Much of the activity of this scenario happens outside of the application and provides context for the developers. For example one inferred user story for the context might reflect that since many brewpubs have muted mood lighting, the application will need to be readable in low light scenarios. This is a non-functional requirement. A user story could be constructed to tackle this requirement.

Tom “Brewdog” Pinternick wants to be able to see the app in low light situations so that so that the application is usable in brewpubs with varied lighting schemes.

Other possible ways to tackle this (and other) non-functional requirement includes adding criteria to the definition of done or by adding specific acceptance criteria to all user interface related user stories. For example, the team could add “all screens must be readable in low light” to the definition of done or as acceptance criteria for screens.

In both cases, these proposed user stories would need to be groomed before a team accepts them into a sprint. Grooming will ensure that the story has acceptance criteria and fits the INVEST (independent, negotiable, valuable, estimable, small enough and testable) criteria we have suggested as a guide the development of quality of user stories. Once a story has been created and groomed, the team can convert the story into something of value (e.g. code, hardware or some other user facing deliverable).

I am occasionally ask why teams can’t immediately start working as soon as they think they know what they are expected to deliver. The simplest answer is that the risk of failure is too high. Unless teams spend the time and effort to begin to find out what their customers (whether a customer is internal or external is immaterial) want before they start building, the chances are they will incur failure or rework. Agile embraces change by building in mechanisms for accepting change into the backlog based on learning and feedback. Techniques like personas, scenarios and user stories provide Agile teams with a robust, repeatable process for generating and interpreting user needs.

 www.spamcast.net

Listen Now

Subscribe on iTunes

In this episode of the Software Process and Measurement Cast we feature three columns!  The first is our essay on the Agile release plans.  Even after 12 years or more with Agile we are still asked what we will deliver, when a features will be delivered and how much the project will cost.  Agile release plans are a tool to answer those questions.  Our second column this week is from the Software Sensei, Kim Pries. Kim asks why is baselining so important. Kim posits that if we do not baseline, we cannot tell whether a change is negative, positive, or indifferent—we simply do NOT know. Finally Jo Ann Sweeney will complete the communication cycle in her Explaining Change column by discussing delivery with a special focus on social media.

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 

I am beginning to think of which book will be next. Do you have any ideas?

Upcoming Events

QAI Quest 2015
April 20 -21 Atlanta, GA, USA
Scale Agile Testing Using the TMMi
http://www.qaiquest.org/2015/

DCG will also have a booth!

Next SPaMCast

The next Software Process and Measurement Cast will feature our interview with Stephen Parry.  Stephen is a returning interviewee.  We discussed adaptable organizations. Stephen recently wrote: “Organizations which are able to embrace and implement the principles of Lean Thinking are inevitably known for three things: vision, imagination and – most importantly of all – implicit trust in their own people.” We discussed why trust, vision and imagination have to be more than just words in a vision or mission statement to get value out of lean and 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.

IMG_1249

I first read The Goal: A Process of Ongoing Improvement when I actively became involved in process improvement.  I was bit late to the party; however since my first read of this business novel, a copy has always graced my bookshelf.  The Goal uses the story of Alex Rogo, plant manager, to illustrate the theory of constraints and how the wrong measurement focus can harm an organization. The focus of the re-read is less on the story, but rather on the ideas that have shaped lean thinking. Even though set in a manufacturing plant the ideas are useful in understanding how all projects and products can be delivered more effectively.  Earlier entries in this re-read are:

Part 1                Part 2                  Part 3                      Part 4                Part 5           Part 6             Part 7

 

Chapter 21: This chapter is bookended by Alex’s martial travails. The chapter opens with Alex making a date with Julie (Alex’s wife). I remember the first time I read the book being worried about Alex’s ability to set a date and time and meet it . . . heck, his plant can’t meet dates.

When Alex’s team identifies the late orders (which was easy), they find that the majority of the late orders are processed through one or both of the bottleneck steps. Some people conceive of manufacturing sector as a set of assembly lines in which the process seldom, if ever, varies. The description of the manufacturing in The Goal is much more akin to a job shop in which the process steps vary depending on the job. This is VERY similar to much of the work done in software development, enhancement and maintenance. If you surface read The Goal you might not see the applicability to software development or other business processes because of this false impression.

Alex tasks his team to ensure that the work following through the bottlenecks is focused on the critical orders. The team sets out to implement the initial wave of changes they discussed with Johan. As with any change the unless specifically addressed those asked to change do not automatically understand why which casues resistance. The Goal uses two situations to push the ideas of communication and transparency as a change management tool. The first occurs when Alex finds the NCX-10 is not running. The inventory for the next critical order is not at the machine therefore the operator is waiting. The material is at an earlier stage. The operator did not recognize the material as being important, therefore opted to follow standard operating procedure. This scenario generates one of the best lines in the book, “if you have to break the rules to do the right thing, maybe the rules are not the right rules.” Similarly, the union head immediately pushed back when asked to change the work rules needed to keep the NCX-10 running during lunch and breaks. Alex recognizes that everyone needs to see the big picture and needs a signal to know which work behavior is needed. Based on these two issues, Alex immediately implements two changes. The first is a   signal card (red tag) to indicate priority orders (very similar to Kanban), and second Alex and his staff begin briefing EVERYONE in the plant (transparency, one of the pillars of Scrum) on the the impact of the changes they were being asked to make. The transparency of the management team about reason the plant was being asked to change helped sway the union.  After Alex personally address everyone in the plant in small meetings the union agreed to the work rule changes and the other changes begin to take hold.

Alex’s date with Julie? In the end Alex showed up on time and they went for the date.

Chapter 22: Alex reviews the progress with his team. The situation has improved by ensuring that the priority orders move through the bottlenecks first and moving quality control to before the both of the bottlenecks. Before the changes the latest order was 58 days behind, now the latest order was only 44 days behind. The problem as Alex sees it, it is not enough.  Goldratt speaking though Alex says, “a few weeks ago we were limping along; now we’re walking but we ought to jogging.”  The changes generated some progress, but not enough. Alex pushes Donavan to address the other ideas that they had addressed with Johan, These included outsourcing some of the processing through the bottlenecks to generate capacity.

As they use the signaling system (red card = a critical order), they begin to discover problems. For example, parts that are queued for processing through the bottleneck steps are not easily distinguishable before and after the process, risking mistakes.  A yellow flag is added to the red card to signal processing is complete (the changes to the process is a reflection of an attitude of continuous process improvement). Alex points out that he does not want stop gap measures and is assured that his team will get to the bottom of the problem, fix the process and re-train the staff (dealing with the deeper issue is a reflection of a culture where root-cause analysis is performed so that problems aren’t just glossed over). The tweaks to the process improve throughput, but don’t generate the quantum change the plant needs.

The chapter ends with Donavon, who has been missing in action, who shows up with the old machines of type that the NCX-10 replaced. Even though, as they put it, the machines he had scavenged from another plan were “state of the art circa 1942″, but they provided extra capacity for the bottlenecked NCX-10. The added capacity, when implemented, will increase the capacity of the bottlenecked step. Remember the overall process capacity is directly governed by the capacity of the bottleneck.

I was talking recently with a Scrum team that included a product owner, coach, 4 coders and one tester. The tester was the only person allowed to test. It had been six months since the team was consistently able to complete a story during the sprint it was accepted in. They wondered if increasing the sprint duration from one week to three would solve their consistency problem. We built a Kanban board to visualize the flow of work through the team. Once the board was built it was immediately apparent that the bottleneck was the single tester. The question I left them to wrestle with was whether the answer would be to reduce the number of coders (implement work-in-progress limits) or to increase the number of testers (add capacity). This is a real life example of how the ideas and concepts expressed in The Goal are just relevant in the world of software development as they are in manufacturing.

Summary of The Goal so far:

Chapters 1 through 3 actively present the reader with a burning platform. The plant and division are failing. Alex Rogo has actively pursued increased efficiency and automation to generate cost reductions, however performance is falling even further behind and fear has become central feature in the corporate culture.

Chapters 4 through 6 shift the focus from steps in the process to the process as a whole. Chapters 4 – 6 move us down the path of identifying the ultimate goal of the organization (in this book). The goal is making money and embracing the big picture of systems thinking. In this section, the authors point out that we are often caught up with pursuing interim goals, such as quality, efficiency or even employment, to the exclusion of the of the ultimate goal. We are reminded by the burning platform identified in the first few pages of the book, the impending closure of the plant and perhaps the division, which in the long run an organization must make progress towards their ultimate goal, or they won’t exist.

Chapters 7 through 9 show Alex’s commitment to change, seeks more precise advice from Johan, brings his closest reports into the discussion and begins a dialog with his wife (remember this is a novel). In this section of the book the concept “that you get what you measure” is addressed. In this section of the book, we see measures of efficiency being used at the level of part production, but not at the level of whole orders or even sales. We discover the corollary to the adage ‘you get what you measure’ is that if you measure the wrong thing …you get the wrong thing. We begin to see Alex’s urgency and commitment to make a change.

Chapters 10 through 12 mark a turning point in the book. Alex has embraced a more systems view of the plant and that the measures that have been used to date are more focused on optimizing parts of the process to the detriment to overall goal of the plant.  What has not fallen into place is how to take that new knowledge and change how the plant works. The introduction of the concepts of dependent events and statistical variation begin the shift the conceptual understanding of what measure towards how the management team can actually use that information.

Chapters 13 through 16 drive home the point that dependent events and statistical variation impact the performance of the overall system. In order for the overall process to be more effective you have to understand the capability and capacity of each step and then take a systems view. These chapters establish the concepts of bottlenecks and constraints without directly naming them and that focusing on local optimums causes more trouble than benefit.

Chapters 17 through 18 introduces the concept of bottlenecked resources. The affect of the combination dependent events and statistical variability through bottlenecked resources makes delivery unpredictable and substantially more costly. The variability in flow through the process exposes bottlenecks that limit our ability to catch up, making projects and products late or worse generating technical debt when corners are cut in order to make the date or budget.

Chapters 19 through 20 begins with Johan coaching Alex’s team to help them to identify a  pallet of possible solutions. They discover that every time the capacity of a bottleneck is increased more product can be shipped.  Changing the capacity of a bottleneck includes reducing down time and the the amount of waste the process generates. The impact of a bottleneck is not the cost of individual part, but the cost of the whole product that cannot be shipped. Instead of waiting to make all of the changes Alex and his team implement changes incrementally rather than waiting until they can deliver all of the changes.

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

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.

Follow

Get every new post delivered to your Inbox.

Join 4,274 other followers