Managing Requirements your way (Part 3)
Several customers and friends reported to me that they would like to embrace Agile methodologies for their development team. Most of them are, however, concerned about how to Manage Requirements with such an approach. In this post I’m going to provide a few hints that could be beneficial to parallel Agile methods with some light-weight Requirements process.
The Agile Requirements Process
More and more development teams now embrace agile methodologies to enable more dynamic and accelerated project schedules. Agile methodologies such as XP and SCRUM acknowledge that business now moves at a fast pace, and that change occurs frequently and out of necessity in a changing competitive landscape. To that end, organizations have also evolved their requirements management processes – away from a waterfall approach, where requirements are developed up front and handed off to development – to a more agile requirements process that is more tolerant and adaptive to constant change.
An agile requirements process looks like this. First and foremost, elicitation, the initial phase of the requirements process, is not a separate and distinct phase covered by the Agile methodology. Rather, Agile assumes that the customer/end user is an active team member, who contributes to the discussion throughout every phase.
Discussion around requirements occurs during Agile meetings, possibly with Wiki support to facilitate discussion on complex designs and specifications. In the approval stage, user stories are created and assigned to developers on the team. In the verification stage of the process, the same developers present their designs, and explain the implementation of the user stories. During the acceptance phase, stakeholders and users check the product, but likely lack awareness of the existence of other user stories. If change is required, early user stories are simply discarded and forgotten. New user stories are created to correct behaviors and operations within the product.
Agile Process Pros
- Only a small tool investment required – open source or inexpensive defect/change tracking tools will suffice
- Low process overhead
- Developer-friendly
- Easily absorbs change
Agile Process Cons
- Applicable only to a software development project
- Poor process visibility
- Stakeholder interaction is difficult – stakeholders must remain in constant contact with development to remain up to date
- Change triggers a new development path
- No knowledge-sharing
A Better Way – Polarion Requirements + Agile = A More Dynamic Requirements Process
Polarion® Requirements™ can dramatically improve the agile requirements process, enabling more effective collaboration between team members and remote/removed stakeholders, and facilitating reuse of knowledge. Here’s how:
- In the discussion phase, team members can use the Polarion Requirements Wiki to capture and draft discussion notes, and document meeting minutes. The Wiki format allows freeform discussion to flow among team members, and invites collaboration and idea sharing.
- The Polarion Requirements Wiki then feeds the creation of user stories, and manages the lifecycle of each user story.
- Every stakeholder – even those remote or removed from the team, can participate and has visibility into the ever-changing process through Polarion, which provides complete traceability over discussion threads and project progress against key milestones.
- Polarion’s seamlessly integrated Wiki and issue management support enables the Wiki to serve as the root and focal point for change tracking, allowing user stories to naturally evolve, but in a managed way with full traceability and control.
- Polarion Requirements preserves and tracks the complete lifecycle of a user story over time, enabling the team and stakeholders to leverage knowledge and reuse for future projects, thus contributing to overall team efficiency, productivity, and cost control.
Seven Ways Polarion Requirements Benefits the Agile Requirements Process
- All stakeholders are involved, including those remotely located.
- There is complete traceability over discussions.
- There is complete visibility over the project’s progress available to all.
- Costs remain low as there is a minimal need for tooling (open source or low-cost issue/defect tracking).
- Tool investments can be leveraged for both issue tracking and user story tracking.
- Change can be tracked and managed.
- There is full knowledge capture so future projects can reuse user stories and implementation experiences.
What’s next
In the next post we will address the Formal Requirements Management process, with some tips about how to apply and improve it in your environment.
Editor’s Note:
Stefano Rizzo is VP for Product Management at Polarion Software. He oversees the strategic development of Polarion’s software products. You can read his profile at http://www.polarion.com/company/people/index.php.
