top of page
  • Writer's picturePaul Gravina

Gathering Requirements in the Agile Environment, don't make it a game of “Gotcha”

As a team, we must find ways to set and meet goals, rather than focusing on mistakes (bugs). There are many challenges when it comes to requirements, testing, and development for an Agile team, and for me, it is always been first and foremost “Requirements”. Agile does not use the traditional style business requirements or functional specification documents, instead, we use small cards (or in our case the wiki) which detail ONE feature. We would conduct more meetings down the road to hash out additional details about the feature with collaborative meetings and discussions. I have a few ideas that I have used to gather the requirements so I can build high-level User Stories. First and foremost ASK QUESTIONS! • Ask the business “what do you need to accomplish”. • What are your goals for the change in the application of the creation of the application? • Ask a user of the system “what do you need to accomplish your goals”. Remember if you can’t state the benefit then you might not need that particular feature. • Clarify any gaps in their understanding of what is required. Do you understand the underlying architecture? If not I will explain. Remember that in the agile environment the Test (QA) teams have greater visibility into the entire requirement request from the business owner through to the system level and can make informed decisions, (testing, timelines, architecture, environments, etc) with that knowledge. You will be testing as early as possible and continuously throughout the application project lifecycle so expect that the code will be written while you test, pretty interesting since you are developing off the requirements. You start to see how important the role of a Business Analyst is or whoever assumes the customer role in the gathering or the dissemination of the requirements, they become front and center on an agile project. Business analysts sometimes need to act as coaches to customers, helping them define concise and very clear requirements. They will have to edit the product backlog, analyze backlog, block scope creep, and prepare the team for the 2 weeks iteration sprints (or time-boxing). Focus your efforts on making the requirements document the most accurate and up-to-date artifact of the project.

1 view0 comments


bottom of page