Search This Blog

Thursday, January 13, 2011

What is an agile BA?

Recently there was a discussion on the Agile BA Linkedin discussion group about the difference between an agile business analyst and a traditional business analyst, if there is such a difference. One group held that all the attitudes, behaviors and activities that were attributed to an agile business analyst in the discussion are actually attitudes, behaviors and activities all business analysts should have or do agile or not. The discussion was mostly theoretical and philosophical. So here is another more pragmatic view of the difference and I am not making this differentiation as a declaration of some agile business analyst manifesto, only to perhaps clarify thinking by presenting two extremes.
When the business analyst is focused on producing a single approved requirements document at the end of a long period of structured elicitation, investigation, analysis, review and approval, and the document is passed on to the development team with or without interacting with the development team, then the business analyst is acting in a traditional business analyst role.
When the business analyst elicits and analyzes the information to produce just enough requirements for the development team to produce at least a rudimentary version of the result and then continues to revise the requirements as the business stakeholders, development team and business analyst learn more about the system delivering the final requirements document describing the system in production at the same time as the system goes into production, then the business analyst is acting in an agile business analyst role.

Saturday, January 8, 2011

When are requirements done?

A question came up recently about when requirements are done. When can you say that you have completed the requirements and there is nothing left to add?
The answer is probably never. Given unlimited time and resources there will always be more information that you can obtain that will change the requirements you have specified, or add new ones, or delete old ones, up to and including changing the entire solution. Had you started a project in 1992 and planned to have the software requirements finished in a year with the target platform being a CICS 3270 terminal. You might have found yourself redoing all the requirements the following year when Windows 3.1 was announced, and then again a couple of years later for Windows 95 and the web and Java (all came into commercial use in 1995.
The bottom line is that the requirements are always complete and correct, assuming you've done proper analysis, based on the information you have gathered and confirmed up to this point in time.
However, a guideline is still demanded. So, here goes: when you have a solution to the business problem and have specified everything the business needs to do to solve the problem, the business requirements are done. When you have specified everything that is necessary from a technical perspective, the system requirements are done. And when you have specified everything that needs to be completed for the project to be successful the project requirements are done.
That doesn't mean frozen or unchanging - just done at this point based on the information you have at that time.
The real answer is that the requirements for the system or change that is implemented are done when the system or change is in production, and subsequent requirements become subsequent changes.