Requirements Management in Scrum Projects
29 July 2015
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.
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.
Current rating: 3 (6 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.