I was reading an interesting blog post about requirements within Agile processes. It’s a topic I have been discussing with my team as we struggle to find the appropriate balance of process and agility.
The big “a ha” for me was the concept of “done” requirements. The author has written about this in a book, so I will be digging in further to further suggest process changes. We use a “done” criteria in our user stories and it seems there are parallels to this concept. This would give the developers more insight into the state of the requirement which would allow them to commit to implementing the feature.
It also implies that there is a need to have dedicated business analysis resources on Agile teams. We do have this role on the team, but it has not yet morphed into the dynamic role it needs to be. We’ll keep working on it. A few years ago an Agile Business Analyst was indeed an oxymoron in the Agile community, I think, because we didn’t understand that requirements (in the form of user stories) are still needed.
Thanks to Ellen Gottesdiener, the author of the post. Very enlightening, indeed. I feel like what I have been saying to my team for the last 3 years was correct.
