Requirement Gathering & Significance In Agile

The profession of analyzing the business requires flexibility, responsiveness, creativity, innovative thinking, acceptance of change, and a dependence on individuals and interactions. Such qualities are desired, if not required, regardless of whether the business analyst is involved with agile software development, traditional software development, or no software development at all. We may not be able to find a “business analyst” job title in an Agile team, but wherever the value of the team to the organization is addressed, someone performing business analyst tasks is going to be required.

To have a successful project delivery using the Agile Software Development Methodology, gathering project requirements is the first critical step.

Why and How Requirement gathering is different in Agile project methodology?

In traditional development model (e.g. Waterfall), requirements were gathered up-front and ‘locked’ in the analysis phase of the project. They could be changed only through formal change requests. In an agile iterative project; the customer doesn’t need to work out all their requirements in detail up front. Instead the broad scope of the project is defined upfront; and then each iteration we analyse enough requirements to support the delivery of that iteration’s functionality. Additionally, if a new requirement we hadn’t thought of comes in, we can re-prioritize the functionality without going through expensive change control.

Agile Requirements are short and can be user stories. Each represents a small piece of functionality that provides some value to the business. It will typically take the form “As a … I want … so that …”. It says who needs the requirement, what it needs to do and why it is needed.

How we do implement and practice Requirement gathering in Agile project methodology

In our recent project which was run using Agile methodology, we tried to follow some of the key techniques of business analysis. Here in this blog we will give you a purview of how we implemented some of the key commandments of business analysis in our project –

Workshops

Requirement workshops are well structured meetings with the stakeholders to discuss the major variables and what is required to achieve them. The aim of this meeting is to find all the potential requirements and decide if it is required to achieve the project’s scope.

For the project, we divided the project scope into functional sections. Each workshop was focused on a particular functionality and involved the user specializing in the functionality, the product owner, Business analyst and the Architect.
The main goal of the workshops was to:
- Understand the current process.
- Understand the “Why” in every process.
- Identify the pain points.

Good Practices that we do follow:
- Have a Structured Conversation: While it is necessary to have questions prepared before a workshop, it is important to ask open ended questions and make it a conversation rather than a QA session. The idea of having questions is to ensure a structured conversation takes place during the workshop.
- Focus on what the problem is before solving it: The workshop should be used to listen, understand and absorb the problem and the requirements. Discussing solutions and implementation during a requirement workshop should be avoided.
- Don’t Assume: If there is any doubt, gain clarity by asking. Bad assumptions can lead to lack of clear understanding and affect the project deliverables.

Documentation of Requirements:

A user story is an informal, general explanation of a functionality written from the end user’s perspective i.e. What is expected by the user while using the functionality? It is accompanied by a set of conditions known as the Acceptance Criteria that should be met by the product to avoid unexpected results after the development is complete. There are many ways to document the user stories and the Acceptance Criteria and the structure depends on what fits the product and requirements best.

For the generally prefers Scenario Oriented Acceptance Criteria. This method we particularly chosen as it makes writing test cases easier and also provides clarity to the non-technical audience. All the requirements were documented in JIRA for easy tracking and visibility to all the project members.
Good Practices:
- Structured Requirements. There are different structures available to write the AC. This may depend on the nature of project, the project scope and the end user of the project.
- User Stories are requirements not Implementations: It is important to focus on the “What” while writing a user story instead of the “How”. Focusing on the solution in a User Story would limit the developer’s creativity and flexibility.
- Confirm Understanding: A way to ensure all the requirements are drafted correctly and can be understood by the user is to have a play back session before the development starts. The business Analyst can go through the user stories and the prototype (if created) to confirm everyone’s understanding.

Prototype:

In business analysis, a protype or a mockup usually means a representation of a mock screen and a user flow, about how the user will interact with the application to accomplish the business problem. The business analyst creates the prototype, generally with the help from the User Experience Design team and technical team. Prototyping is key integral task for a BA who is dealing with requirements related to a product design. The visual output is more tangible and easier for the stakeholders to understand. The cost of building a prototype is usually a fraction of the planned cost for overall solution.

For our project we used prototypes for UX cognitive testing, customer feedback and stakeholder sign off. For complex expensive platforms we resort to wireframes or mockups because the stakeholders have a difficult time visualizing a solution to the business problem without an actual prototype. We also realized having a high-fidelity prototype helped developers understand the requirements, functionalities, process flow and general UI aspect of the project.

Good practices:
- Make it Fast: It is important to remember that the objective of a prototype is to get an understanding of a problem. It is important to keep that in mind and not be tempted to build the entire product. Its good practice to define the features and ideas in advance, so that it is quicker to build it.
- Ditch the Details: Colors and other fancy visual details make the webpage/app very desirable. But these design techniques are not top priority for a prototype. The key here is to think in terms of bare minimum. This step is after all, the way of testing new ideas and having visual effects could be a major distraction.
- Prioritize Features: When building a new webpage/app, it is easy to get excited about new features and get carried away. It is important to prioritize the features that are integral to the app. The best features should focus on the business needs.
- Use real content in Prototype: Content is a large part of a prototype experience. Although underrated, it is important to have real/actual content on the prototype. It gives the user a better understanding about the product. If you do not have the final content/text, create an approximate of the actual content.
- Accept Negative Feedback: Learning how to accept negative feedback is one of the most important lessons of prototyping. When receiving negative feedback, stay calm and do not get upset. Prototypes is a tool to test ideas, they can be easily swapped out and discarded.

Showcase:

“Showcasing” provides a platform for all stakeholders to get together at the end of the Sprint to review what the team has worked on and provide their feedback on the functionality, which is being built. As software requirements are subjective hence it’s important for all stakeholders to view the implementation and ensure what’s built is in line with the expectation. The distributed nature of software development makes showcases challenging and hence it’s pertinent to plan and prepare for showcase in advance.
Good Practices:
- Planning: Its always important schedule the showcase so that all the key stakeholders can attend. It is important to send the agenda of the showcase in advance. Before the showcase it is suggested to test all hardware/software that would be used for showcase.
- Presentation: Start the showcase by summarizing what you’d cover before diving into the details. Walk through the user journeys-Personify the user and what the user would do. Ask questions/feedbacks for each module before moving on.
- Closure: Summarize all showcase action items towards the end. Share the showcase notes with action items to all participants.

Why and How Requirement gathering is different in Agile project methodology?

How we do implement and practice Requirement gathering in Agile project methodology

Workshops

Documentation of Requirements:

Prototype:

Showcase:

Madhubanti Chakraborty

Saloni Praharaj

Written By Madhubanti Chakraborty

Products

Categories

Let’s Create Big Stories Together

Contact Us

Australia

Level 13, 200 Queen Street Melbourne VIC 3000
Australia

India

B Wing, Level 2, Ghule Square DSK Ranwara Road, Bavdhan,
Pune 411-021

Singapore

2 Shenton Way #15-04 SGX Centre 1, Singapore 068804

USA

196 N 3rd Street, Suite 319, San Jose,
CA 95112

Thanks for showing an interest in our products.

Requirement Gathering & Significance in Agile

Why and How Requirement gathering is different in Agile project methodology?

How we do implement and practice Requirement gathering in Agile project methodology

Workshops

Documentation of Requirements:

Prototype:

Showcase:

Madhubanti Chakraborty

Saloni Praharaj

Written By Madhubanti Chakraborty

Products

Categories

Tags

Australia

Level 13, 200 Queen Street Melbourne VIC 3000 Australia

India

B Wing, Level 2, Ghule Square DSK Ranwara Road, Bavdhan, Pune 411-021

Singapore

2 Shenton Way #15-04 SGX Centre 1, Singapore 068804

USA

196 N 3rd Street, Suite 319, San Jose, CA 95112

Level 13, 200 Queen Street Melbourne VIC 3000
Australia

B Wing, Level 2, Ghule Square DSK Ranwara Road, Bavdhan,
Pune 411-021

196 N 3rd Street, Suite 319, San Jose,
CA 95112