{"id":191551,"date":"2019-06-27T12:53:44","date_gmt":"2019-06-27T07:23:44","guid":{"rendered":"https:\/\/staging-imarticus.kinsta.cloud\/?p=191551"},"modified":"2021-03-10T07:53:42","modified_gmt":"2021-03-10T07:53:42","slug":"knowledge-center-agile-agile-requirements-with-karl-wiegers-whats-the-big-deal","status":"publish","type":"post","link":"https:\/\/imarticus.org\/blog\/knowledge-center-agile-agile-requirements-with-karl-wiegers-whats-the-big-deal\/","title":{"rendered":""Agile Requirements With Karl Wiegers: What\u2019s The Big Deal? ""},"content":{"rendered":"

Software companies are using Agile methodology and even the BAs are calling their work \u2018Agile Requirements\u2019. According to Karl Wieger<\/a>, there is a huge difference between the activities for requirements on traditional and agile projects. Rather the work specified as \u201cagile requirements\u201d is not very conceptually different having evolved from the traditional waterfall methods. The major areas where requirements activities are handled differently are discussed below.
\nResponsibilities and roles:<\/strong>
\nIn Agile the elicitation, specification, reviews and analysis of requirements is a collaborative team-process with the product owner, analyst, key stakeholders, developers, and other business user representatives.
\nThe roles in Agile need the PO to be responsible for the backlog of products and preparing the user stories for implementation. The developers ensure the information of the user stories is sufficient for development. Some projects may have the BA as a PO while others may use a dedicated BA to help the PO prioritize and elaborate user stories.
\nTiming:<\/strong>
\nTiming of the requirements is crucial to projects. Traditional methods create a detailed project requirement report at the very beginning including the basic sequencing, estimation and prioritization chores. Agile, however, relies on a just-in-time approach where requirement details are generated before the implementation of sets of functionalities.
\nThis approach no doubt ensures the information is up-to-date. But, it can be blind to the dependencies of requirements and implications on the architecture. That\u2019s why the teams look at the broad project scope and architectural requirements in early iterations. Adding functional requirements happens on an on-going basis and in small doses of releases, unlike the traditional processes. While agile can produce more small marketable releases in one project cycle any error in the requirements of a traditional project can be expensive to re-work or re-do.
\nBoth methods focus on risk mitigation to enable forward movement on the project. However, agile teams anticipate rework, refactoring and testing making them ready to accept iterations and rework.
\nFig-1. Standard requirements that occur with agile iterations.
\nDeliverable Forms:<\/strong>
\nUser stories are in reality use case individual flows. The traditional BA may use cases to flesh out the functional requirements. In contrast, an agile project uses the specific requirements of a user story in writing the granular acceptance tests and ensuring the right implementation of the story.
\nUsing the very same information one method describes what to build while the other specifies how to know if you\u2019ve built it right and functional. Tests are very useful in discovering the chinks in specifications. Using just one method is hence a limited view. Ideally, the incorporation of both views is good. However, Agile teams are limited by the roles of the team and specify that the product owner writes the acceptance criteria and user stories.
\nTerminology:<\/strong>
\nWhile traditional methods use functional requirements and use cases Agile projects call them acceptance criteria and user stories. No matter what you call the terms it is essential that apt communications help the testers and developers do their job better. This leads to efficiency and effective productivity.
\nDetailing and Documentation:<\/strong>
\nLight-weight documentation is the norm on Agile projects unlike the document-reliant traditional practices since developers and customers frequently communicate and collaborate.
\nThe requirements are precisely developed by the BAs or as a team responsibility through recorded conversations and very few standard regulation-required documents.
\nMany Agile user stories list the help of the analysis visual model and acceptance criteria to list the highest\/ riskiest-impact functionality. The costs of acquiring information are high and to save time projects should adapt to just-enough recorded documentation for risk management.
\nPrioritization:<\/strong>
\nIn Agile, backlog prioritization is continuous and undergoes many iterations. Items remain on the backlog when under-development and get discarded if not workable. This is not the case with the traditional methodology where the requirements are prioritized at the project onset and not really reviewed frequently. The impact of prioritization on ALL projects needs dynamic management of the backlog as an essential best-practice.
\nConcluding Notes:<\/strong>
\nProjects need to define their business-value and ensure that their business-processes and project activities add value to their prioritized practical methods. While Agile is certainly beneficial for projects the BAs practices and principles falls more into a traditional role. It is also true that most Agile teams lack BA specific organic expertise.
\nTo learn how the \u201cagile requirements\u201d are somehow different and special do an Agile course at the reputed Imarticus Learning Academy<\/a><\/strong>.<\/p>\n","protected":false},"excerpt":{"rendered":"

Software companies are using Agile methodology and even the BAs are calling their work \u2018Agile Requirements\u2019. According to Karl Wieger, there is a huge difference between the activities for requirements on traditional and agile projects. Rather the work specified as \u201cagile requirements\u201d is not very conceptually different having evolved from the traditional waterfall methods. The […]<\/p>\n","protected":false},"author":1,"featured_media":191562,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_mo_disable_npp":"","_lmt_disableupdate":"","_lmt_disable":"","footnotes":""},"categories":[24],"tags":[842,850,1236],"class_list":["post-191551","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technology","tag-change-management","tag-agile","tag-agile-business-course"],"acf":[],"aioseo_notices":[],"modified_by":"Imarticus Learning","_links":{"self":[{"href":"https:\/\/imarticus.org\/blog\/wp-json\/wp\/v2\/posts\/191551","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/imarticus.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/imarticus.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/imarticus.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/imarticus.org\/blog\/wp-json\/wp\/v2\/comments?post=191551"}],"version-history":[{"count":0,"href":"https:\/\/imarticus.org\/blog\/wp-json\/wp\/v2\/posts\/191551\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/imarticus.org\/blog\/wp-json\/wp\/v2\/media\/191562"}],"wp:attachment":[{"href":"https:\/\/imarticus.org\/blog\/wp-json\/wp\/v2\/media?parent=191551"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/imarticus.org\/blog\/wp-json\/wp\/v2\/categories?post=191551"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/imarticus.org\/blog\/wp-json\/wp\/v2\/tags?post=191551"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}