User stories for production support part 2: PAC

I wrote an article on stories for production support teams quite a while ago.  But I always meant to add a couple more.

The problem with production support is that nobody has time to ask for what they want, but it is all urgent and super critical. So the last thing you often feel like doing is to slow down and understand the context that the user is in (annoyed, relaxed, sitting in a cafe, in their most important sales meeting ever etc). Instead the focus is usually on fixing “it” before you know what “it” really is.

But this often leads to rework. So whenever I am doing enhancements I always spend a little time understanding why the enhancement is needed, who it is needed by and when/how it is likely to be used in the real world. To do this though, I think we always need to spend a little time understanding the people who will use the system and why they need something new.

There are many approaches to doing this, but one I often find useful is “PAC” or “People, Activities and Context”.

PAC refers to a series of steps to understand:

  • The People using the system;
  • The activities they will perform; and
  • The context in which they will perform them.

The steps are quite straightforward:

P: People (Define the users)

Let’s start by breaking “the users” into three groups:

  • Those who actually use the system for the purpose we built it for are the Primary users.  Most regression testing is likely to focus on these users;
  • The often forgotten Supporting users are those who interact with or use the system for the purpose of helping the Primary users to use it. For example production support or on-site support engineers; and
  • Other stakeholders are those who do not directly use the system but who gain a benefit from the system or have a say in what it does.

Example primary users might include:

  • Experienced and inexperienced users
  • Wholesale and retail customers
  • Users of different versions of the software – Basic Edition, Advanced Edition and Enterprise Addition for example.
  • Local users and overseas users
  • Onsite users, home users and mobile users

In each case you list the types of users and then ask yourself:

  • Do they use different functionality?
  • Do they use the same functionality differently or need a different experience using it?

A: Activities

The next step is to list the typical activities that the user might perform, that might impact or involve the system.

The trick here is NOT to just go through the requirements. Instead the focus is on the user and “what they will do during the day”.

So we might have a requirement for a user to login and another requirement to process member enquiries. But we might actually put down the activities of “talk to customers on the phone” and “send a report to the boss”.

Sending a report to the boss might involve running a report from the system (and thus match a requirement) or it might involve collecting information from several sources, including the system we are building.  So the user might actually be logging into our system to run some general queries or to just look at some screens.

Similarly, several users might do the same activity, or one activity might involve multiple users. So don’t worry about linking the activities to a specific user yet, just put them all down in a list.

So the idea is to capture “what activities does a user get involved in”.  These can then become the basis for requirements, test scenarios, stories, use cases or whatever you want.

C: Context

The final component of PAC is context.  This is important because the same user might perform the same activity very differently at different locations, using different toolkits or even in different emotional states.

So context can cover anything about the user’s environment or situation, for example:

Physical environment:

  • Will this be done at the office, at home or on the road.
  • Some users might be in a major company while others are in a small office.
  • Some users might be in the outback in Western Australia while others are in a major city in Japan.

Technical environment:

  • Will all users be using the same operating system, browser version etc. I find in particular that customers assume we support all browsers in all versions but IT. departments only test with one browser, assuming any others are unsupported.
  • What hardware will people be using?  Will this impact their response times or ability to see our graphics.

Emotional state:

  • During a disaster might be a different process to relaxing at the office.
  • The user might be using the system in front of a complaining client or after work.
  • when there is time to wait for reports to run.

Time

  • Is there a specific time when things are harder or more urgent, for example peak hour or the annual enrolment week at university where things will be both more important and more likely to fail;
  • Are there blackout times like overnight backups, annual reporting periods or change freezes?

Bringing it together

Now that you have collated all the information you join the dots. So you look at each user and ask yourself whether they will do each activity and in what context they will be operating.

You can put this all in a table if desired:

People Activities Context
Primary users

  • Experienced online customers from large organisations
  • Experienced small operators
  • Inexperienced users
  • Potential customers

Supporting users

  • Onsite system administrators
  • Our call centre
  • Production support

Other stakeholders

  • The internal audit team
  • Sales and marketing
  • Compliance
Enter new customersCollect money from customersRun reports for management

  • Weekly status
  • Monthly reconciling

Pay out customer entitlements

Install the software

Look for problems when it fails

Using a browser online

  • IE current version
  • Other browsers

Using an ipad or galaxy tab

While a customer waits

  • On the phone
  • In front of the user

At the end of the day

Physically worn out

  • After 4 hours in the coal mine

From home or on the road

  • Logging in from hotels or the airport
  • Checking data from the car or while in a cafe

 

Of course completing the table is not the point.  The real point is to use this information to create stories, requirements or tests.

Advertisements

4 thoughts on “User stories for production support part 2: PAC

  1. Pingback: Scenario testing the cycle of pain for regression testing « James King

  2. Pingback: A simple product summary to help requirements « James King

  3. Pingback: Regression testing – day 1 « James King

  4. Pingback: Defining the value or your internal consulting team part 3 – reviewing your services | James King

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s