This is the first in a series of posts describing Attivio's approach to Agile from an implementation perspective. Requirements management is one of the most interesting parts of planning in an Agile environment. The challenge lies in balancing Agile's fundamental acceptance of frequent requirement additions and modifications, against investing time in defining those same changing requirements at a detailed level. This challenge is especially apparent when the scope of your development project is large.
Attivio's Active Intelligence Engine (AIE) has a huge number of high-level requirements and writing stories for all of them would be a monumental task. Fortunately, in Attivio's early days, the engineering and business teams had so much subject matter expertise, we understood many if not all of the key AIE information access requirements; therefore, we were able to define general use cases on the wiki and were able to track individual features at a high-level and not take the time to write complete use cases for every feature. That being said, we did perform detailed requirements definition for our innovations and other complex pieces of the system.
As AIE has evolved and Attivio has grown, we can no longer rely upon shared understanding for a large portion of new product features; therefore, we've evolved our Agile development tracking tools and practices to accommodate a larger set of participants and the increasing complexity of stakeholders and feature dependencies.
Today, Attivio tracks requirements using Atlassian Software's JIRA ticketing system. Requirements are tracked in two groups using default JIRA ticket type designations: "New Feature" tickets and "Tasks" or "Improvement" tickets. Ticket types are assigned using the following rule of thumb:
-
Features that are customer-facing (i.e. the customer cares about them, they should appear on product sheets and/or sales/product teams need to be aware of them) receive the "New Feature" designation and are labeled with an external product version number e.g. "Version 1.2", "Version 1.3", etc...
-
Other features such as configuration parameters, performance improvements and other low-level technical features (typically documented only in developer documentation) are tagged as "Tasks" or "Improvements" and are labeled with a Sprint version e.g. "Sprint 15", "Sprint 23", etc...
The two types of version labels allow us to create parallel backlogs, one that makes sense to the business stakeholders and one that makes sense to the Engineering team. We've found this useful as, in practice, there is little to be gained from asking a sales or product team member to evaluate the priority of adding a new display function to the UI versus exposing operational capabilities via JMX. In addition, when sales or marketing wants to know what's already in a release and what is still slated for an upcoming release, it is much more efficient to provide them with a "New Feature" report out of JIRA for the external version rather than have them sift through a huge amount of internal improvement and task tickets that are tracked at the sprint level.
In my next post, I'll walk through Attivio's requirements management cycle and version planning.
Note: While many of our approaches aren't "pure" Agile, we believe we've created a best- practices process that embodies the "spirit" of Agile in that it has been developed iteratively, with the constant input of the engineering team based on key Agile principles.
Trackback(0)
 |
TrackBack URI for this entry
