Roles with Teeth

As a trainer, I have noticed that when I start the "Roles, Personas and Goals" discussions, attendees in the room are 40% more likely to start surreptitiously checking e-mail their smartphones than they when we talk about comparatively exciting topics such as "stand up meetings," "story boards," the "burn up versus burn down chart" debate, or "evolutionary design."   I had to lure you to this blog post, in fact, by riding on the coat-tails of the Breaking Dawn, Part 1, premier tonight at midnight.  You aren't interested!   You have heard it all before!  "To write good software, you need to know who will be using it and what they want to accomplish."  Blah blah blah--sounds like something your mom would say.   "Give the roles names, and think of them as people.  If multiple types of people play the same roles, give them different names, and call those things 'personas'"  Now you sound trendy and slightly unhinged.  Let's go back to the burn-ups.

Let's not!  I'm going to simulate a "requirements" conversation with your business users twice, for purposes of comparison.  "Before" will represent what you may be doing now.  "After" will represent the same conversation, except that all players focus in a disciplined manner on roles and goals--who is doing the action and why?  Could it be that such a slight change of focus will give you measurable improvements to your software?  I say yes!

Before ("the system shall"):

Analyst:  "So to complete requirement A-445, after the screen prompts for the three criteria, if the first check box is activated and the fine amount is under $50, the save button is disabled and an error message is displayed."

Business user:  "Right"

Analyst:  "So we're done then?"

Business user:  "Yes."

After (someone in particular is doing something for some reason):

Analyst:  "So who has access to the screen where you can enter the fine amount?"

Business user:  "The receptionists in the front office."

Analyst:  "Let's call our sample receptionist 'Gayatri,' okay?

Business user:  "Um, okay, if you say so."

Analyst:  "All right, so a person who lost their library card walks up to Gayatri, and Gayatri brings up the a screen where she can enter the fine amount.  She asks whether the person has lost a card before, and if the answer is yes, the fine needs to be $50 or more, depending on her mood.  If not, they can get a new card for some amount less than $50, based on a sliding scale that Gayatri maintains.  Is that right?'

Business user:  "Um, no, actually not.  We have a triage person who handles the library card issues.  If the person has lost their library card more than ten times, the triage person calls an armed escort to take the person out of the library forever.  If it's less than ten, the triage person updates a flag on the person's record to show that it's either the first card lost, or some number larger than that.  They're the ones who update the 'repeat offender' flag."

Analyst:  "Okay, let's call the triage person Jens."

Business user:  "Uh huh."

Analyst:  "Does Jens use the same screen that Gayatri uses?"

Business user:  "No, Jens gets a screen with a panic button and no fine amount.  That's why I didn't bring it up.  We're changing the rules around fine amount, not the repeat offender flag.  Do you agile guys get partially lobotomized before they let you loose?"

Analyst:  "Would you expect Gayatri to need to update the repeat offender flag, or should it be locked down?"

Business user:  "Hm.  Interesting point.  We're instituting this new rule to ensure that the library can protect its fine revenue.  We set up Jens's job in the first place to separate enforcement from the clerical function of just putting in the fine amount."

Analyst:  "So the 'repeat offender' flag should be disabled on the fine entry screen?"

Business user:  "Yes it definitely should.  We don't want Gayatri gaming the system.  We've had a history of soft-hearted admins resetting patrons to non-offenders just to take a little bit of money off of the fine.  They're just enablers.  Those people are monsters--they go through ten, fifteen library cards a year!"

Analyst:  "Yikes!  Okay, so we're making two changes to the fine entry screen:  first, lock down the repeat offender flag and only allow it to be edited on the panic screen by Jens.  Second, enforce that when Gayatri hits 'save,'  if the repeat offender flag is set to 'yes,' she must collect $50 or more."

Business user:  "Yes, that's right."

Analyst:  "So we're done then?"

Business user:  "Yes."

This may seem like a fanciful and trivial example, but I hope it illustrates the point.  In this case, actual library revenue could have been affected if one field had been left editable rather than changed to read-only.  Moreover, by describing actual people doing actual tasks, this analyst was able to find out about a whole additional screen she didn't know about before.  I've been on projects where analysts focused on "the system" didn't find out until months into actual software development that "the system" was only one of TWO systems that Jens, Gayatri, and the other imaginary personas were using to keep data up to date.  The work load for the project doubled in a day, once someone shadowed an actual data entry person to see what they did.

People-focused requirements gathering is the only type of requirements gathering trustworthy enough upon which to base your company's cash flows, or anything else important to your operations.  Even if you are an analyst who is a subject matter expert in her own right, take the time to mentally walk through the process as performed by your actual end users, and don't focus too quickly on the details of "the system" and "the screen."  The focus on people itself is important, and it will bring you and your company significant return on investment.

This post is from Pragmatic Agilist by Elena Yatzeck. Click here to see the original post in full.