Innovate 2012-Achieving Better Requirements on Agile projects-User stories and beyond
Cherifa 270001GAPC Visits (4044)
Here is Edward bear, coming downstairs now, bump, bump, bump, bump on the back of his head…..It is as far as he knows, the only way of coming downstairs.. but sometimes he feels that there really is another way…..(A.A Milne, Winnie-their pooh)
This is about the paradigm shift or doing things differently!
I was recently invited as a speaker for a Business Analyst (BA) Day and my topic was “Do requirements really matter in agile”. Business analysts continue to be challenged to meet rapidly changing business demand and adjust to the agile world. Those BAs who understand what it entails to be working in an agile environment and meet the agile principles will have the competitive advantage. There is no such thing as an “agile business analyst”. A BA is a BA and no matter what development process (hybrid, waterfall, agile) you use and how light or heavy this process is. If you have the skills required to be a BA, then you should adapt to the different waves of development.
I will be speaking at Innovate 2012 on “Achieving better requirements on Agile Projects and the eight Habits”. The session will be held on Wednesday, June 6th, 2012. My presentation's topic is one of the debates that are happening right now among the business analyst community (world wide). I would like you to get going with this discussion before the conference and after, and ask you to share your insight, experience, and how you made the paradigm shift to Agile as far as the requirements definition
What my presentation is about
Business analysts are struggling with the new paradigm shift. They see a lot of challenges in addressing the requirements in such an agile environment. Questions are being asked and those are: where are my requirements? How much detail do I need? How much enough is enough? How do I address the quality of services (Non functional requirements) and constraints? The user story does not seem to hold all information I need? Where are my business rules? You told me to maintain focus on the acceptance criteria and acceptance tests? Why? Where do those come from? Do they make up for my requirements specifications?
It is my experience that detailing requirements is something teams do even in an agile world but when and how makes the whole difference from a traditional requirement definition and management (RDM) process.
While requirements are not necessarily neglected on agile projects, this may erroneously take a waterfall approach to requirements.
Ensuring that the requirements remain “agile, there are some common set of principles that an agile team adheres to when it comes to elicit and define requirements. If you really understand those agile principles and apply them “smartly”, you can succeed!
This session outlines reasons why RDM is critical to success in agile development and discusses eight habits that agile teams should adopt for highly effective requirements definition and management.