In articulating agile requirements, best practice is to write user stories. A user story follows the 3 Cs process – Card, Conversation, and Confirmation.  At team level, a product owner who represents the business owns the story card.  The product owner through the card briefly states from a business perspective what she wants the delivery team to build.  The card is generally stated in the user story format of As a <user role> …I would like <build functionality>….so that I can <achieve a business goal>.

The story card was originally intended to be written down on a 4×6 index card.  The requirement in this case are barely sufficient to convey the intent and idea of what needs to be built and the details are left for latter conversation with the team and the Product Owner.  The acceptance criteria were sketched out on the back of the card.  The card serves as a reminder for a future conversation.  In the traditional software development, going through staged gates and going through functional silos, meant more emphasis on writing things down.  That is how we did handoffs from one stage to another, from one functional team to the other.

With Agile, we sketch out our idea about the requirements with the assumption that at the onset of the project, we don’t always have perfect information and that information and situations do change on the ground during the implementation of the project.  We also have cross-functional teams which obviate the need of writing detailed specifications.  So for example, a cross-functional team with development, QA or test, analysts, and database resources won’t need explicit documentation as each of these team members participate in all conversation regarding their backlog and projects.  These conversations could in formal meetings such as planning sessions and story grooming sessions or informal conversations with Product Owner and other stakeholders.

So far so good, all of this has now been well understood with the basic agile approach to requirements articulation.  But, with the use of Agile Lifecycle Management Software, sometimes Product Owners and teams have tendency to forego the brevity required with the use of 4×6 index cards.  Soon, if you are not careful, a story card starts resembling software specifications documentation.  Similarly, scaling Agile to multiple teams and multiple projects sometimes necessitates that the Product Owner role would get further refined.  Leffingwell highlights two distinct set of responsibilities: one that is market/customer facing product managers and another that is solution/product/technology facing product owner (Leffingwell, 2010, Loc 4078 of 10384).  At a high level, Leffingwell assigns these responsibilities to each of these distinct roles:

Agile Product Owner Agile Product Manager
Product/Technology-facing Market/customer-facing
Co-located (may report into development/technology) Co-located (may report into marketing/business)
Focuses on product and implementation technology Focuses on market segments, portfolio, ROI
Owns the implementation Owns the Vision and Roadmap
Drives the iterations Drives the release

With this type of distinction, it generally falls to Agile Product Manager to own the higher level Feature and Epic definitions at the program/project level; whereas, the Agile Product Owner is focused at the sub-epic, story level with their respective teams.

As the Product Owner responsibility gets split, product management and their respective teams have a tendency to revert back to form and rely heavily on process, and on the ALM software, which then starts resembling the traditional requirements gathering process.  Product Managers may engage in heavy requirement sessions and considers that to be the end all and be all.

But fundamentally, the concept of 3Cs doesn’t go away with Agile scaling – the Agile Product Manager can still maintain just enough documentation at the feature and epic levels and then use conversation with other Product Owners to drive the details, just as a Product Owner would do for lower level epics and story with their respective teams.  The concept of having information tomorrow than today still holds.

Mike Cohn makes 3 points regarding writing requirements down in details and relying on it as a primary communication tool (Cohn, 2009, pg 237): 

  1. Written documents make things official, team members will suspend judgement about challenging it.
  2. Written documents tend to discourage everyone from iterating over the intent and meaning as we do in conversations
  3. Written documents are instrumental in creating seuqential hand-offs and they tend decrease the whole-team responsibilites

So the key then remains in having conversation within the product management team and then laterally with the agile teams so that ambiguity can be driven out, intent can be clarified, and the story boundaries can be defined, on a continual basis as new information gets uncovered about a project.


  • Leffingwell, Dean, 2010, Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise, Kindle edition, Addison-Wesley Professional.
  • Cohn, Mike, 2009, Succeeding with Agile: Software Development Using Scrum, Addison-Wesley Professional.