Role Storming

UPDATE: This excercise is ideal for large projects with many SME’s in the room.  In this case I was building a Loan Orgination System for a bank with 10+ SME’s in the room that were all arguing with each other about the Persona’s and thier behaviors this took two days to do but the outcome was well worth the effort. If you have 1-4 SME’s this is possibly overkill.  Be pragmatic not dogmatic. 

Scott Butner's Flicker photostream

Occasionally I am brought in to facilitate story break down sessions. I have to admit that this is one of the more enjoyable aspects for me when dealing with large Agile project because it allows me to learn a ton of information about the business domain.

One of the first exercises I go through is a Roles Storm. This is an exercise that gets the customer to think about the different types of behaviors that certain roles and personas can perform in their software that they are asking you to build. This exercise helps me to hold story authoring sessions in the future.

I try to focus the discussion towards the lowest level persona that does something. The template of the exercise is very simple:

A {Persona/Role} can …

In this case I will use the “Loan Rep” persona.

A Loan Rep

- can view their own pipeline

- can order a credit report

Once we establish the lowest common denominator you simply move up the chain:

A Processor

- can do everything a Loan Rep can do and

- can upload to desktop originator and loan prospector

As you can see I am able to start identifying lots of domain concepts. DO NOT try to dive deep with this exercise. Its focus is around brainstorming of Personas and Roles only. Let the customer do most of the talking. Do not let this turn into a technical discussion.

WARNING: This list does NOT contain stories, it contains concepts for stories but it does NOT contain stories!!!!

Preparation time for this exercise is a few minutes but the event usually last at least a full day.

In the end you end up with a list that looks something like this:


Back Office (Centralized Admin)

Super User
  1. can do what the help desk manager and business admin can do,
  2. can defines profiles,
  3. can maintains universal system tables,
  4. has access to the entire application,
  5. can delete loan records from the system, (flag to stop display of record in any pipeline view – only available to admin and can be identified on reports.)
  6. can update mortgage center home page content,
  7. can create admin users,
Help Desk Manager
  1. can do what a team lead can do,
  2. can be given the permission to delete loan records from the system,
  3. <revisit> can reset loan events,
Help Desk Team Lead
  1. can do what a help desk user can do
  2. can add and maintain users,
  3. can create and maintain loan centers, (full name of lender in table – online view would be an abbreviated version)
  4. can maintain peer level admin profiles or lower,
  5. can pull lead between reps and processors within a loan center,
  6. can push lead and loan records to other loan centers,
Help Desk
  1. can add and maintain mortgage center users,
  2. has system wide read only access,
  3. can invoke a system wide search
Business Admin (Centralized)
  1. can add and maintain loan programs and fee schedules,
  2. <revisit> can create and maintain printable documents,
  3. <revisit>can maintain dropdown tables (ex. Marketing codes, loan conditions),
  4. can add new contact types and global contacts.
Loan Office Admin (Loan Center)
  1. can pull lead between reps and processors within their loan center(s),
  2. can push lead and loan records to other loan centers,
  3. can modify user permissions within their specified role within their loan center,
  4. can make a user inactive or active within their loan center,
  5. can make user available or unavailable within their loan center,
  6. <revisit> shared roles,
  7. can be given access to assign loan to themselves,

Field Roles

Loan Center Manager
  1. can do everything a processor can do,
  2. can pull lead between reps and processors within their loan center,
  3. can push lead and loan records to other loan centers,
  4. can modify user permissions within their specified role within their loan center (include permissions to access loan center pipeline)
  5. can make a user inactive or active within their loan center,
  6. can make user available or unavailable within their loan center
  7. Can delete leads across loan centers and users (no credit ordered)
  1. can do everything a loan rep can do and
  2. can upload to desktop originator and loan prospector,
  3. can export FNMA 3.2 file,
  4. can add and maintain conditions to a loan,
  5. can submit loan package to lender,
  6. can print all documents,
  7. can add and update lender denial and counteroffer,
  8. can view all teams pipelines within their loan center,
  9. can edit any lead or application within their loan center,
  10. can run reports for their loan center.
Loan Rep
  1. can add and edit & delete their leads in the system but cannot delete an application (credit has been ordered),
  2. can view their own pipeline,
  3. can order credit,
  4. can include and exclude liabilities from the 1003 section,
  5. can complete full 1003,
  6. can order appraisal,
  7. can order title,
  8. can add notes to conversation log,
  9. can add contacts,
  10. can create rate locks,
  11. can print 3 day disclosures,
  12. can select loan programs and fee schedules,
  13. can print the 1003 blank or otherwise,
  14. can import 1003,
  15. can view and print rate sheets,
  16. can flag loan as withdrawn,
  17. <revisit> task creation and assignment,
  18. can submit lead to processor,
  19. can push lead to another user,
  20. can collect and record upfront fees,
  21. can run reports for their pipeline,
  22. can make themselves available or unavailable
  23. can be given permission to pull from loan center pipeline (public queue)

About Joe Ocampo

My personal philosophy is simple: "Have a good strategy that sets the environment for success through the enablement of the whole. Be agile but with a mind towards pragmatism. Delegate to the best qualified individuals, but don’t be afraid to involve yourself in all parts of a job. Treat everyone with respect, humility, and with a genuine pursuit towards excellence." Respected business and technical leader with expertise in directing organization towards effective results driven outcomes. Proven ability to perform and communicate from both technical and business perspectives. Strong technical and business acumen developed through experience, education and training. Provides the ability to utilize technology, harness business intelligence and execute strategically by optimizing systems, tools and process. Passionate about building people, companies and software by containing cost, maximizing operational throughput and capitalize on revenue. Looks to leverage the strengths of individuals and grow the organization to their maximum potential by harnessing the power of their collective whole and deliver results. Co-Founder of
This entry was posted in Agile Project Coaching & Management, Agile Teams. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

4 Responses to Role Storming

  1. Tobin Harris says:

    That’s cool. I like the focus on *listening* to the customer :)

    This is also very similar to the user-task list that Alistair Cockburn talks about in “Writing Effective Use Cases”. The user task list isn’t the same as use-cases, it’s early brainstorming for who can do what (identifying roles and goals!).

    Role-storming – nice name :)

  2. Joe Ocampo says:


    I tool like to *listen* to the customer but I usually employ these mechanism when I have a room full of 10+ SME’s in the room are large enterprise Agile projects. If it were just 1 – 4 people I would do what do you do and just listen.

  3. Great stuff. I think the key ‘how to make it work’ advice is to not dive deep during this elicitation session. Personally, I struggle with that. Diving deep matters, it just needs to be deferred. I think about domain discovery / scoping as a “broad and deep” exercise – first, go broad across everything, then go deep on one thing. Imagine surveying for a drilling operation. You survey all of the available land, then pick the most promising spot and start drilling. Then the next most promising.

    This is a great way to organize those survey results.

    In enterprise projects, I’m often dealing with SMEs from distinctly different areas of the company, who don’t know anything about the other areas of the company. They are focused on specific areas (like channel versus retail, or finance versus manufacturing). This is a great approach to allow the SMEs to get a shallow understanding of what happens in the other areas of the business, and how their silos work together in the bigger picture.

  4. Tobin Harris says:


    I wasn’t clear in my comment – I was saying I like the fact you said you focus on listening:

    “Let the customer do most of the talking.”

    That means you’re doing more listening thank talking, which is really important IMHO :)

    I’ve found these user-task lists very useful for scoping out small projects too.