Busted! 8 Common Beliefs That Get in the Way of Improvement
Myth 1: Use Cases are requirements
Use Cases only describe process flow and are not ideal for capturing data flow and business rules. Two other critical elements of information are still needed to develop requirements. Secondly, Use Cases are ambiguous. They do not explicitly define system capabilities, since a business Use Case may have one or more manual steps. Finally, the requirements are the GAP between the current state and the future state, whereas Use Cases are either the current state or future state. Use cases are a technique of analysis that helps lead to well framed requirements.
Myth 2: Requirements are not required for Agile Development
In fact, in most versions of Agile development (except XP) even structured analysis techniques like Use Cases might be used, however, in deference to IAG’s agile practice team, let’s talk user stories and epics for written requirements. Agile, like any other development methodology, is reliant on building up an understanding of backlog. The techniques of user requirements elicitation are different as are the role definition, and the process of requirements elaboration. In fact, a true agilest (using Scrum methods for example) would use terms like Scrum meeting, Scrum team, Sprint 0, Sprint plan, walking skeleton, and epics to refer to these plan driven concepts.
Agile strategies typically fail in the absence of techniques for eliciting needs and having improved approaches to elaborating these needs as sprints progress.
Myth 3: Business Analyst are not needed in an Agile Development environment
Agile uses different role definitions and preaches the concept of ‘self-managing teams’ with high functional interaction between expertise areas on an ongoing basis. Plan driven development, on the other hard, is typically more hierarchical, with more functionally independent activity followed by managed hand-off points between functional groups.
The role of the analyst morphs since it is more interdependent and decision oriented – you might even say ‘empowering’ – to an analyst that ends up as the Product Owner or (less likely) the Scrum Master. A central tenet of Agile/Scrum, for example, is that a single point of decision making (called the Product Owner) exists which can guide understanding of needs including defining features, deciding on release dates, ensuring profitability, prioritizing features and outcomes, accepting or rejecting work, etc. Given the heavy cross-functional nature of business, extremely senior analysts that are able to objectively represent the needs of the business often end up being a superior fit for this role as opposed to an executive which represents only one lens on business need.
Myth 4: Requirements meetings are not practical in our organization
This is an excuse to cover up lousy elicitation skills and techniques. Any complex application has many interdependent business processes and functions. It is simply not possible to get managers to decide how these processes are going to work without bringing these functional teams together.
The process ends up taking 4 times as long if you run a series of serial meetings.
Click Here to read more