In Part 1 of  this article, I talked about the new skills and attitudes business analysts need to bring to agile development... Now it's time to talk specifics. What exactly do BAs do in agile development? How will your activities differ from those of traditional development? Let's take a look at agile business analysis from the perspective of the activities that make up requirements development and management, comparing traditional with agile analysis.
 

Although it may seem obvious that the User Interface (UI) directly impacts usability, and therefore satisfaction, Business Analysts often find themselves focusing on functional requirements to ensure end user satisfaction. Mainly, this is due to the non-functional requirements, like usability, being dictated by existing technology or process within the organization. However, research into mobile user interfaces is placing the focus back on the usability requirements as the main driver of user satisfaction.

"How do I move into the field of Business Analyst?" or "How do I move up within the field of Business Analysis?" These are common questions heard in today's job market. Whether you are a programmer, a software engineer, a business subject matter expert (SME) who wants to transition into a Business Analyst role,a recent graduate who is trying to determine how to break into the B.A. job market, or your company just one day changed your title to Business Analyst,this article contains a list of 12 things you can do that will help you connect with the vast community of knowledge and resources.

Much of the current buzz about SOA has been focussed on the technology (inevitably Web Services) or the importance of reusability. However the real value of SOA is in the improvement to processes and ways of working that reflect the alignment of an organisation with its customers and suppliers.  The approach we favour is one that begins by aligning the business and technical understanding of the concepts of SOA, from both the business process and technical architecture perspective.
 

With current economic conditions, companies are striving to do more with fewer resources, both human and material. So it should be no surprise that the fusion of business processes and practices is both relevant and necessary. Over the past two decades business methodologies and corporate programs have established track records that demonstrate performance and quality improvements within their organizations.

When the first flowcharts were applied to manufacturing processes, they followed the flow of a single part through its manufacture.  They displayed, in sequence, the steps it took to make the part and they made sense.  They were easy to visualize, easy to follow, easy to work with, and they resulted in millions of dollars worth of productivity gain. 

This same concept was applied to information process charting in the 1940’s.  However, rather than following a single flow, multi-flow process charts were used.  They showed all of the records in a business process in order to make clear the exchange of information between records.  Once again the effort generated millions of dollars worth of productivity gain.

From a developer's standpoint, few things are more frustrating than having to make lots of calls and research to learn what to create because the requirements are ambiguous. From an analyst's view, few things are more frustrating than having your requirements misunderstood. Yet so often, requirements are ambiguous to their readers, despite the writer's best efforts.

A process is a series of steps completed to achieve a particular result. It is hard to imagine a process improvement effort that doesn’t start with a focus on that result with a question like “What is the purpose of this process?” - whether the customer is actually engaged or not. Sometimes we have a strong sense that our product or service is good. Sometimes we choose to “get our own house in order” before we step outside the organization. Sometimes we base the result on a prescription provided by the customer. However, sometimes, our focus may be misdirected to how we do the work without considering why it is done in the first place...particularly where slick new technologies are involved. In any case, without actually engaging the customer, we can’t really know how well the process is working to provide the customer with what the customer needs or wants.

Quality requirements contribute to the success of agile and traditional project management projects. The requirements definition process followed in a traditional project management framework and the features-based storyboarding that is typical of agile approaches are different, but they also have many similarities. The actual process used to define and gather requirements may be different, but the criteria for quality requirements remain constant. What are these similarities and differences in the process of gathering requirements? What happens to the role of the business analyst in an agile environment?

I am not sure if there are many other fields in corporate America that require the finesse necessary to execute the professional pushback as greatly as business analysis. Just by the shear nature of what analysts do, we are constantly uncovering inefficiencies and making recommendations for improvements or enhancements. Sometimes those recommendations are system-focused but they can also be people and process focused.

If requirements management practices were songs entering a popularity contest, requirements validation would hardly be a favorite contender. It's easy to understand why: validation is usually a tedious, time consuming task, and, as with nearly every quality control activity, it is supposed to reveal defects, going against our natural desire of being right, not making mistakes, and singing in tune.

Agile development practices introduced, adopted and extended the XP-originated "User Story" as the primary currency for expressing application requirements within the agile enterprise. The just-in-time application of the user story simplified software development and eliminated the prior waterfall like practices of overly burdensome and overly constraining requirements specifications for agile teams.

However, as powerful as this innovative concept is, the user story by itself does not provide an adequate, nor sufficiently lean, construct for reasoning about investment, system-level requirements and acceptance testing across the larger software enterprises project team, program and portfolio organizational levels. In this whitepaper, we describe a Lean and Scalable Agile Enterprise Requirements Information Model that scales to the full needs of the largest software enterprise, while still providing a quintessentially lean and agile subset for the agile project teams that do most of the work.

Most analysts are introduced to SOA in one of three ways; two of which are potentially painful and one of which is actually useful. I’ll let you decide which you would prefer.

The path to requirements elicitation is something that analysts are rarely taught. Everyone knows that it involves interviews and research, but within most organizations, exactly how the interviews and research should be conducted is nebulous.

Babies and Business Analysts go through four stages, as they open their eyes and see. 

In Stage 1, with eyes closed, BAs are blind to their organization’s mess.

In Stage 2, as their eyes begin to open, BAs see in black and white: a single process step, template or isolated requirement.

In Stage 3, the mobile movement of the outside world attracts and delights them: industries, methodologies, collaborations and emerging trends.

In Stage 4, they strengthen their muscles: the analytical and creative skills used to facilitate organizational futures and protect their parent enterprise in this new economic climate.