The Best Guide To Agile Requirements Gathering

In this session we are going to cover agile requirements gathering, their importance in developing quality software, and how you as a QA engineer can make an impact.

Follow the Agile journey for Success

Our XBOTalk 7 part series we will address AGILE and the Key Solutions to the most common Software Development Pain Points related to Software Quality. By the end of this 7-part series you’ll understand:

✅ Agile Requirements Gathering

✅ Agile Sizing (Epic / Story / Task)

✅ Testing Manual vs. Automation

• What makes a good candidate for automation?

✅ Test Asset Management (highlighting Jira Plug In)

• Storage
• Organization in to groups

✅ Automation Script writing

✅ What is a quality gate, and how to use

✅ KPI

The art of defining clear agile requirements. 

First, let’s discuss the problem in that there are many challenges of converting a business concept to a viable software product. This can only occur through defining clear requirements.  One most common pain points voiced within the software community is the frustration caused by requirements which are not fully defined, or are modified as the development process progresses.

Agile requirements gathering

An Agile requirement gathering starts vague and is refined and becomes more as it progresses from concept, to Epic, to Story, to Task.  One of the weaknesses of Waterfall is that the majority of the work to refine the requirements is done during the design stage, and adjustments needed later in the cycle are expensive and create development delays.  Our discussion will focus on the Agile process of refining requirements through iterations.

Quality needs to be built into the requirement development process from conception through delivery.  One of the key considerations when constructing a requirement is how it will be tested. If the requirement covers new functionality for an existing application, dependencies need to be identified to be placed in testing tasks.

Illustration of Agile requirements gathering

To understand how to take a requirement from concept to delivering a usable product that meets a user’s needs, we’ll use the analogy of building a house.

Using that analogy, there are potentially seven groups involved in creating, implementing, testing, and deploying a requirement, prior to it being put into production.  Let’s talk about the role of each group:

#End users – (Homeowners)

The group who uses the product once it is in production, the expert on whether the product is what they need, and able to contribute valuable feedback on improvements.

End users provide exploratory testing. As they use the product, they report functionality that does not work as they expect it to work or suggest improvements after they have used the product. They test the product from the perspective of how they want to use it.

#Client – (Real-estate developer) 

This group pulls the vision together to offer the product to the end users.

Clients provide user acceptance testing. This group of users understands how the product should work, test with this understanding in mind, and test with predetermined standards, which ties back to the agile requirements gathering.

#Business Analysts – (Realtor)

They act as the liaison between the client, and potentially the end users, to move from concept to requirements.  This group is the first line of defense on clear agile requirements gathering, and they need to ask specific questions:

• Who will be using the product?
• What does the final product look like?
• Are there any risks which need to be mitigated?
• Are there any dependencies?

Business analysts test the requirement from a perspective of how they interpreted the requirement should work, build tests as the requirement is being finalized to test their understanding.

#Software Engineer – (Construction Crew)

Pulls the product together into a cohesive deliverable, and builds the complete product.  In terms of the house analogy, think of the components which go into creating a house such as foundation, frame, infrastructure, internal and external walls, windows, doors, and roof.

The software engineer will build unit tests to prove that they are building to the requirements specified for each component.

#Quality Assurance / Performance Engineers (Building Inspectors)

Tests the build for compliance to requirements, verifies the dependencies, product works as expected, verifies messages, visual and performance aspects of build are acceptable to client and end users. Using the house analogy, think of verification of hurricane straps to attach the roof to the foundation, the plumbing is attached to the input and output, the electricity works as expected, all light switches and electrical outlets are live.

Let’s turn our focus to how to identify a well-formed requirement in agile.

Comparing the good and the bad of agile requirements gathering

The most common complaint about agile requirements gathering is that requirements are changed, that they are not specific enough, or are open to interpretation.  Let’s work through examples to show the difference between a well-defined set of requirements and requirements which will lead to confusion.  Continuing with the house example let’s look at 3 sets of requirements, then examine what is good or bad about each set:

#Requirement gathering set one:

Need a two-story house, with 3 bedrooms, 2 bathrooms

Analysis: Wide open to interpretation, end-users could be envisioning one style of house, and the team builds their very interpretation of the requirement.  In Agile terms, this could be the back of the napkin level of requirements definition.

#Requirement set two:

• Two-story brick house
• One Master Bedroom, with ensuite bathroom, and walk in closet
• Two standard Bedrooms with a bathroom between
• Stairs from center of the house to second floor

Analysis: In this set of requirements, there is more guidance, but it’s still very open to interpretation. In this case the team can still choose the style of the house, and there is no definition about the layout of the first floor, window requirements, or clear vision of the final product.  In Agile requirements gathering terms this may be the level the team gets to during a quarterly planning session.

#Requirement set three: 

• Two story brick house, built in a traditional style
• Slate roof
• Five windows in the front wall
• Solid front door painted blue
• Six step stoop to front door
• First floor
  • 5 rooms – Living room, Dining room, ½ Bathroom, Kitchen, Study
  • Stairs from first floor to second floor
• Second floor
  • Hallway connecting rooms, and landing for the stairs
  • Master Suite
    • Bedroom
    • Full Bathroom
    • Walk in closet
  • Two standard bedrooms
  • Full bathroom, connecting the standard bedrooms
  • Laundry room
  • Drop down stars from attic to hall

Analysis: The basic structure of the house is well specified, the team can start on the project, the details for each room will be specified as the project progresses through the agile retrospective and planning ceremonies.  One of the keys to successful requirements is to understand how much detail the requirements need for the team to start a project, and how to add details and stories during the planning sessions.

Key to solid agile requirements gathering 

The key to solid requirements is asking for the correct level of detail.  Once the initial requirements are specified, the team needs to evaluate them for completeness, identify dependencies, and a delivery order.  Most organizations want to deliver a minimum viable product first, which means prioritizing delivery according to user wants and needs. A strong requirement has clear acceptance criteria.  Acceptance criteria is used to build test cases. And both need to answer at least one of the Why, What, When, How questions:

• Why
  • Why are we working on this project?
• What
  • What do we hope to accomplish by completing this project (sprint/build)?
  • What do we need to accomplish in terms of resources, software, or hardware?
  • What are the dependencies?
  • What are the risks?
  • What is the logical order for the requirements?
• When
  • When does the project (sprint/build) need to be delivered?
  • When will the resources be available?
• How
  • How will the project (sprint/build) be approached in terms of Epics, Stories, and Tasks?

Agile requirements from a Software testing point of view

From a software testing point of view, testing in Agile needs to start early in the requirements phase by determining if the requirements are testable. QA engineers typically review requirements examining for clarity and completeness, and also give feedback to product managers for requirements that don’t meet these criteria. With clear, complete, and accurate requirements, QA engineers are then able to test criteria for pass/fail that help developers understand the “Definition of Done” for the requirement.

The problem is that in order to do review and provide feedback on requirements requires more than just button pushing of an existing system. Rather, QA engineers have to think from an end-user point of view on what would be acceptable to the user in executing or using the particular function being developed. This requires thinking outside the normal ‘tester’ box, along with domain knowledge of the application.

READ MORE: Testing Your Loan Application Software – 3 Secret Points You Didn’t Consider You Discover the features and functions of loan applications that are important to loan application software testing…. BY JIMMY FLORENT

XBOSOFT manages it all

Now you know one of the key advantages of XBOSoft. We’re not just software testers pushing buttons. We are domain experts in various disciplines with accumulated knowledge that you can take advantage of in thoroughly testing your software from start (agile requirements gathering) to final delivery to your end users. Please reach out to XBOSoft with questions or to request support from our talented team of experts.

In the next XBOTalk episode, we will explore Agile Sizing, where you’ll learn how to identify Agile Epics, Stories, Tasks, and Spikes, using an Agile Sizing approach.

The 5 Key Elements To Successful Agile Sizing In this session, we will discuss the challenges of Agile sizing, Epics, Stories, Tasks, and Spikes

Watch Agile Requirements Gathering Best Practices:

Contact us today to create a functional and usable website.