Whether you are agile or more traditional, your challenge is the same: In order to remain relevant in today’s market, you have to discover and deliver the right thing at the right time. To do this successfully, you need to elicit customer needs and quickly choose from among many competing voices and options to determine what is truly essential and what can wait for a future release. That means selecting the requirements development and management activities that are most effective for your particular situation–whether those practices are in your current toolbox or not.

To understand this mindset shift, it might help to think of requirements activities in terms of the ShuHaRi progression, with a learning stage (shu), a breaking away stage (ha), and a transcendent stage (ri). 

In the learning or Shu stage, both agilists and traditionalists use the requirements practices that are customary for their methodology. For agilists, that’s likely stories, stories, stories. For traditionalists, that probably includes specification text and templates, use cases, and the occasional analysis model.

In the Ha stage, you’ve been around the block and are starting to move away from the familiar. If you’re an agilist, you’ve grown weary of drowning in a sea of user stories. You recognize that analysis is not an evil word and that high assurance products need solid traceability. Consequently, you are looking to broaden and tighten some practices in order to make your stories ready for planning, delivery, and testing. If you are more of a traditionalist, you have realized that you need to break free from oversized specifications and spending so much time detailing features that never get built. You joke that your customers and users don’t recognize you in the hall, because it’s been so long since you interacted with them. As a result, you are investigating ways to narrow and lighten some of your requirements practices.

In the Ri stage, you synthesize practices that work, regardless of whether they hail from agile, emit from the disciplines of testing or user experience, or draw on the wisdom of traditional requirements and business analysis. In other words, you regularly adapt your requirements practices to fit the context of your product and project, from hyper-regulated to experimental to everything in between.

I’ll be giving a webinar next month on how to adapt your requirements practices to fit your particular context or environment. I hope you’ll join me to learn how reaching outside your comfort zone can help you find the best fit for you and your product.

Webinar information (for PMI® members): sign up here, the PMI® Requirements Management Community of Practice website.