So far there’s a word I’ve used sparingly in this series, and have mostly avoided when I could. That word has been agile. Agile represents a huge range of skill sets, suggestions and best practices. It’s a phrase that has been bastardized by many to simply mean “We can wing it”. That isn’t what agile is about. I’ll state this very clearly, agile is about creating a workflow that can reasonably and quickly adapt to user and business needs by uncovering those needs as early as possible.

Agile does not mean “I know you just launched this yesterday, but I need you to add a few features by tomorrow”. We attempt to create a workflow, to get input and feedback in a constant loop from users, and to never need to push out features that are created under highly undesirable circumstances, such as all nighters ending in a early A.M. release.

Why? Because those circumstances suck for the code quality, the developer and ultimately for the business. Bugs are introduced, mistakes are made and sometimes tiny, hidden inconsistencies can create very serious results. The process is not there simply to make us happy, it is there to make what we produce better.

The reason for this rant is that I’ll be using the word agile a lot more in this and future posts in this series. I wanted to get that out of the way before I started.

On to the Business Analyst now.

Introducing The Business Analyst:

The position of the Business Analyst (BA) might need a little explanation, not only for people not used to working in structured environments, but also for those used to working with a traditional marketing team for their software concepts and design.

Even if you have a marketing or product team, it is important to think of them as a business analyst, and get them thinking in the same way.

The business analyst serves as the first line of communication, along with a critical eye as software progresses. The role I will define for them here is outside of their normal scope, but has its reasons.

The Idea – Step 1

As explained in Part 2 of this series, the users must be trained to present a problem to the software team. This is where the business analyst comes in. It’s a very simple process, the business analyst has a brief meeting with the user to discuss the user’s problem and needs as well as to begin the process of requirements gathering and to get an understanding of the businesses needs as they relate to the suggested features.

Prioritization – Step 2

The Analyst should now understand enough of the problem to provide the Architect a rough idea of the requirements, and they (and any other relevant business units) can discuss prioritization. At this point the story enters the backlog of requested stories/functionality, and is processed when its turn comes up.

Specification – Step 3

There is absolutely no value in carefully defining software criteria months (or even weeks) before the first line of code is written. By the time you get to the code base, the requirements have likely changed. Once the story’s time comes up and it is ready to be moved into an iteration/sprint then you can go into story planning.

Story planning involves a significant number of actors. The User is strongly desired for the relevant planning of their feature set, but not required. Required participants are The Analyst, The Architect, The Developers and The QA Engineer. If relevant you should also include The DBA and The Designer as they will play an important part in estimating complexity.

The story planning procedure can be complex, particularly with so many actors in play. The Analyst’s role in this particular segment is fairly complex. The Analyst is there to organize the meeting, run the projector that displays the stories (if anyone is still using pen and paper backlogs…just stop it) and perform any actions taken against the MMFs.

The point of this meeting is to review each MMF proposed for the upcoming iteration, break each one down into a number of User Stories and Tasks and ideally provide a scenario for each task that contains a clearly defined piece of functionality (features, not chores) stated in the Given/When/Then syntax, which can be executed as a test later one.

The common argument here is that this meeting is very expensive because of the number of actors in play. It is important to understand the point of this sort of detailed story planning. Every single person who comes out of a meeting like this will know exactly what was planned, exactly what is intended and often through natural discussion the why of it, and it will reduce both friction and confusion down the road. If the user can be involved, that’s great as they start thinking right from day one about what they might need to change!

Iterations and Review – Step 4:

The role of The Analyst in these reviews is passive. The Analyst is present, assisting with the definition of new requirements if they come up, but for the most part this is a meeting run by The Architect, with participation from The Developers for the sake of The User. QA should also be present.

Remember, these meetings are for The User to stay focused on whether or not the software meets their needs!

Acceptance – Step 5:

The Analyst should ensure that all acceptance tests run and that beyond the functions of QA the basic functionality meets requirements. As each individual User Story is completed, The Analyst should perform acceptance to ensure the business requirements are met. This can occur before or after QA, but ideally it occurs in parallel with.

Post-release – Step 6: 

The Analyst should keep an ear open for any feedback after the release, and through the continued upkeep of a software product. Often The User, now acquainted with The Analyst from working together, will speak to them freely about the software platform they work in. These relationships will be great building blocks for improving communication and workflow as continued work on a software product goes forward.

Conclusion: 

The Analyst’s role is not a minor one, and the part he or she plays in initiating relationships with users can not be understated.