Alternate title:  Oh the joys of documenting requirements on a new Agile project!

Many organizations struggle with adopting Agile since it requires such a fundamental and overarching shift in business process.  Often times the biggest challenge with the new process is how to gather and document Requirements.   I’ve observed that a piece meal approach to implementing Agile is not as effective since the performance benefits are not fully realized unless all Scrum team members and stakeholders are on board. So how do we get everyone on board?

First, it can be helpful for Scrum Masters to recognize that the Agile manifesto value of “Working Software over Comprehensive Document” is a struggle for many Project Management Offices ( PMO) and Business Analysts (BA). Organizations and firms which are heavily regulated have strict requirements on detailed project artifacts in order to pass audits and the PMOs and BAs are oftentimes the creators and/or keepers of these documents. In short, it’s a balancing act to the find the appropriate and agreed to level of documentation that meets everyone’s needs. These discussions and agreements can take place during Sprint 0 and reviewed in the Release Planning meeting.

Waterfall/RUP documentation habits die hard with some seasoned BAs. The urge to analyze, research and detail out full use cases and system requirements prior to the start of sprinting can be strong for those who are new to iterative development and User Stories.   The Scrum Master’s coaching and guidance on the Agile best practices for User Story creation and refinement are critical to keeping the project moving along and not getting bogged down in analysis paralysis.

And then is there is the battle of what tools to use to document and where to store the project and requirement artifacts. Boy can opinions and passions run hot in this area!   Whether you use TFS, Rally, Jira, VersionOne, PivotalTracker or any other application for tracking your User Stories, sprint tasks and velocity, your Scrum team and the Project stakeholders need to understand and come to an agreement that certain Requirement Documents of Record can should be stored, tracked and linked to in other repositories like Sharepoint or Blueprint.   Traceability is a key concern for many organizations and should be addressed in your Team Agreements and processes.

The Goldilocks Dilemma

How much detail do we need to put in a User Story? This is another deeply philosophical question and everyone seems to have a different opinion on it.

How much is too much? How much is too little?   What level of information and detail is just right?

As Scrum Masters, our role is to strike the right balance with the Product Owners, BAs and PMs so that the needs of the organization are met without sacrificing the benefits of the iterative design and development. This is certainly easier said than done but know that you are not alone in this challenge.

It helps to explain that details on the requirements will be uncovered and documented in a more collaborative manner with ongoing conversions and meetings with the entire team. Requirements will not be created in a vacuum and will be refined /groomed/ sized by the scrum team.

It occurs to me that this topic is important and meaty enough to deserve its own article, so I’ll dive into the details of User Story Creation in Part 3 of my “Confessions of a Scrum Master” series next week.

The behavioral changes involved in adopting the Agile can be uncomfortable and difficult for many people and teams. Documenting requirements in Agile often requires a significant shift in process and the Scrum Master’s coaching and facilitation role is critical to helping the team to learn and understand the value and benefits of iterative development while allaying their fears and concerns about the “new and different” way.