A mechanical approach for a BA on an agile project

Recently I wrote a mechanical guide for testers on agile projects, but what about business analysts?

Well it is a bit controversial.  I think you can get a lot of value out of having a BA on an agile project (see my comments here  for example). But others think it is bad luck to have a BA on an agile project, kind of like having a woman on a ship is bad luck if you are a sexist old school pirate.

So if you are in a superstitious agile team, then maybe the first step is to disguise yourself as a tester and change your name to Bob.  That way nobody knows you are a BA.  Go around saying things like “hey let’s break something, I love breaking things.”  and “Are you sure about that?  I am a tester so I never believe anything.”

Next find out what the project is about.  You might decide to do a plan on a page like this one:

If possible it is worth creating a project charter.  This is a bit suspicious because it is a BA kind of thing to do. So break some things first and complain about how people never seem to leave enough time for testing.  That should put people off the scent while you create a charter along these lines.

Now start finding stories and elaborating them.  There are many ways to do this but let’s use an old school BA technique to elaborate.

It will be a dead give-away that you are a BA if you use a business process model or use cases, so let’s try a less well known approach.

Here, I am using the B-5 model that is covered in the SoftEd Business System Analyst course.  I think there is a webinar where Shane Hastie demonstrates how to apply this to agile projects but I couldn’t find it.  So let’s go through the steps.

Our project is to build an app for agile trainers that allows them to manage student attendance.  So one story is “As a trainer I want to upload a class list so I can remember who attended my course”  Another story is “As a course administrator I want to upload a class attendance register so I can record who attended.”

It appears that our project has duplicate stories and maybe gaps.  So let’s apply the model.

Step 1 – take the story off the post-it note and put it in a table.  This is something a tester might do so it should not arouse any suspicion.  The table should have columns for “as a”; “I want” and “So that”.

Step 2 – ask these questions:

Who else does this?  Who uses the output of this story? Who else needs to do something to help?   Add the answers to the “As a” column but don’t worry about adding stories yet.

Now ask “What else does that user want to do with the sytem?”.

Step 3 – Now add stories for all the users.  You should get a growing list of possible stories.

Now also create a separate table called an actor/goal list.  Or to sound agile call it a “persona” list.  The list should just include the users you identified and why they want to use the system.

Step 4 – ask what triggers people using the stories.  As “when do they do this?” or “What happens just before this?”  Add these to a new column called “Triggers”.

Now go through each story and ask “What happens after this story?”; “What happens as a result of this story”.  Add the answers to new rows and see if they result in new stories.

Step 5 – consolidate your list of stories because it is starting to get out of hand.  See if you can group several stories into a blob or “feature”.  Then see if there are any obvious gaps.

Step 6 – Add information.  Ask “What information does the user need access to in order to do this?” for some of the stories.  Then ask “what information is updated or created when we do this?”.

Step 7 consolidate your “information” that is created or accessed into tables, system names or groups of information.

Step 8 – apply “CRUD.”  If you are not sure what this is, don’t worry.

Add the “Information headings” or “data sources” as columns at the end of your table.  Now go through the stories and for each column of “data source”:

• Add a “C” if you create data in that source
• Add an “R” if you need to read information from the data source
• Add a “U” if you update information in the data source as part of the story
• Add a “D” if you delete or archive information as part of the story

Step 9 – Use CRUD to find gaps in your stories.  Every column that is a data source needs to have at least on of each letter in C-R-U-D.  This is because, if you read information it must have been created, possibly updated and one day possibly deleted.  So if you don’t know who creates the information, there is probably a new story where someone creates the information.

Step 10 – You can now do “MOSCOW” in the stories to prioritise them and then stick them in a backlog, or estimate them or whatever agile teams would normally do with their stories.

But hopefully, if you do this collaboratively, someone will get sick of all the work and suggest you create a process model or an ERD or something.  Look surprised and agree.  Before you know it people are acting like BA’s and you will fit right in.  The models you build will be useful for creating and fleshing out stories as well as mapping them together.

But if you are too scared of being revealed as a BA then call this technique “an approach to building test scenarios” and say it is typical testing work.  Or if you want to be more obscure, simply create parts of the table when nobody is watching and pin the components on the wall near the team’s stories.  Act surprised when you see it and claim this must be the work of “BA like brownies”.  Teams who are suspicious usually believe in fairies, so it should work.

This technique can work for converting requirements to stories in semi-agile projects but the main benefit is that it slowly introduces the team to the idea of analysing stories rather than just listing them and bashing them out as code.

Now you have won their trust you can introduce more advanced concepts like transition requirements (analysing what the support team will need if you hand software over to them).  See here and here for example.

The final step is to sneak real analysis into the team’s way of working.  I suggest you recommend story mapping by leaving this link lying around for people to find:

http://www.agileproductdesign.com/presentations/user_story_mapping/

Or better yet introduce the team to the book on story mapping.  This is a really simple and yet powerful way to both create, track and analyse stories on a project, without ever having to admit you are really just doing business analysis on an agile project.

The book is here

Now you just go to all the agile meetings, like any other agilista.  But remember that if you reveal you are a BA, then you should probably sit down with the product owner for a bit of a turf war.  You will need to clarify how you work together.  You can try this template if you like.