Get certified - Transform your world of work today


Requirements Management in Scrum Projects

29 July 2015

Rumesh Wijetunge
Zaizi Asia

The success of any project depends on how the feature requirements are managed. As a qualified Certified Business Analysis Professional™ (CBAP®), Professional Business Analyst (PMI-PBA)®, Certified ScrumMaster® (CSM®), Project Management Professional (PMP), and Agile Certified Practitioner (PMI-ACP)®, and having experience as both a business consultant and as an Agile ScrumMaster, I thought I'd write about my experience and the practices I've used in managing feature requirements.

Requirements management entails planning the requirements activities for the project, requirements elicitation, requirements analysis, documentation and communication, traceability, prioritization, and requirements validation. So what are the best practices in managing the requirements of a Scrum-based project?

Most often than not, a Scrum project would use a tool, such as issue-tracking project management software JIRA®, Team Foundation Server (TFS), or Relational Team Concert (RTC)™, in managing the project activities. In addition to the project management, these tools are used to document and manage the requirements. Any collaboration platform or tool, such as Confluence, may be used in detailing the requirements.

Use the BABOK® tool to create requirements forms and track what should be maintained in your requirements management tool. The BABOK defines four main types of requirements: business requirements, stakeholder requirements, solution requirements (functional/nonfunctional), and transition requirements. All types of requirements may be captured and maintained through a robust requirements management tool.

As we all know, the highest level of requirements in Agile is called an epic. An epic corresponds to business requirements identified through enterprise analysis in which the BA or team identifies the strategic objectives or vision of the customer and documents them as high-level features of the solution. When requirements are defined through collaboration with stakeholders or SMEs, the solution requirements are documented in detail as user stories under each epic. In the case of migration projects, the BA may capture and document data, system, or resource transition requirements as user stories in JIRA (linked to an epic).

When epics are broken down into user stories, requirements are automatically traced from business requirements to other lower-level requirements (backward traceability). Almost all requirements management tools today provide capabilities to tag or associate labels to user stories that may be used to map requirements to different modules or groups of requirements. This tagging allows for lateral traceability or trace relationships among requirements. Finally, when stories are broken down further into tasks, and developers or QA engineers tag their code or test cases to the tasks, the breakdown and tags allow for complete forward traceability of requirements from their origin right up to the piece of code developed to implement that functionality.

These are a few best practices I've implemented when managing requirements. I would definitely like to see your comments or feedback on how you manage your requirements in your Scrum projects.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 3 (6 ratings)


Ash Ganatra, CSP,CSM, 7/29/2015 10:32:55 AM
Should you not disclose that you are promoting your own product here?
Francesco Sferlazza, CSP,CSM,CSPO, 7/30/2015 12:09:56 PM
I would just suggest a more lean approach. A simple Product Backlog with links to a wiki/collaboration tool. Specifications by Example who are converted in (automated) test case. Then, continuous integration, deployment and so on, according with the definition of done.
Are you sure your approach could lead to a hand-off, information scattering and other wastes ?
Rumesh Wijetunge, CSP,CSM,CSPO, 8/3/2015 7:10:39 AM
Well yes, JIRA does support the lean approach you are referring to Franscesco. However, I guess linking the requirements in the backlog to a wiki page is not automated and you need to manually do the linking. Test case automation can certainly be supported with Selenium and continuous integration supported with Bamboo.
Well the approach does support hand-off from BA to dev to QA through workflow steps / stages in JIRA itself. However, like you said managing waste with respect to time may be minimal if the team is not mature enough or if they take undue advantage of the leniencies that come with Agile based development.
Robert Day, CSM, 8/3/2015 7:47:51 AM
I'm intrigued as to how you think that a team might "take undue advantage" of the "leniencies" in Agile.
Rumesh Wijetunge, CSP,CSM,CSPO, 8/3/2015 11:54:03 AM
Well, in a T&M based engagement if the PO is non technical, the team May over estimate time required or under conmit, and in requirements elicitation and documentation the team May slack since they know that they have the flexibility to carry forward stories.. These are a few instances I feel people take advantage of.
Meghan Robinson, CSM,CSPO, 3/17/2016 4:15:17 PM
Would you be okay with us highlighting this article on our new AgileCareers Blog?

You can view the blog here:

I look forward to hearing your response! Thanks.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up