Show notes
In this episode, Barbara Carkenord helps us understand the difference between requirements in agile and waterfall and how to be successful with agile requirements.
After listening to this episode, you'll understand:
- How requirements in agile environments differ from waterfall requirements
- The shift that you need to make to be successful with agile requirements
- How to overcome perfectionism
- What to do if the details aren’t needed right now
Show Notes
What’s the difference between requirements in an agile environment versus a waterfall environment? Not much . . . and a lot.
On one hand, agile requirements approaches are very similar to traditional approaches. You still need to analyze, facilitate, use good listening skills, and manage the requirements.
On the other hand, agile requirements differ in that the traditional, heavy documentation becomes a lot less important. We need to shift our thinking to focus on requirements as an analytical, thinking process. It’s more about discovery and collaboration than about documentation.
You’ll still document requirements in agile, you’ll just likely do so in a lightweight way such as starting with Post-Its or using a flipchart. Think about documentation in more creative ways.
Audit Considerations
If you’re concerned that audit needs more comprehensive documentation, work to understand their true needs. Ask the ‘why’ questions to the audit department, leadership team, PMO, or whoever is asking for extensive documentation.
This approach helps shift the thinking in your organization and helps everyone to understand what is truly needed and the value that an output provides.
Asking questions about why documentation is needed and the value can help you to produce what is needed to the extent required to deliver the expected value. Instead of making assumptions, look at what’s actually required, why, and look for creative ways to meet that need.
The Difference with Agile
Most of the tools and analysis techniques you use in waterfall environments are still valuable and useful in agile.
With agile, many of the business analysis techniques can be same, but the timing and approach may be different. You will likely still need to perform a current state analysis to understand your starting point. The difference will likely be in how much you need to document and in what format.
The key to success with agile requirements is to know when to keep things at a high level and when to get into the details.
Agile requirements and documentation should be barely sufficient; just enough to meet the needs of the team and the organization. Anything more is wasted effort.
Remember that your outputs don’t always need to be perfect. Do just enough to meet the need and create a shared understanding. Force yourself to let go of perfectionism when it doesn’t add sufficient value.
Requirements should also be completed at the last responsible moment. If we create requirements too far in advance, things will likely change and your effort would have been wasted. Often a scrum team will have 1-2 sprints of ready stories and the BA is working slightly ahead to refine the user stories.
You’ll need to balance your time between working slightly ahead of the team and helping the team in the present moment with and questions or issues.
Focus your effort on the most important thing you can do right now today. Know what can wait and know what can benefit from waiting because you’ll learn along the way and may have more information later. Keep in mind that things may change and doing too much upfront can be wasted time.
When you come across ideas that are too soon to discuss, have an organization system for future ideas. It’s important to know when to be detailed and when to keep things at a high level.
You’ll need strong analysis and facilitation skills to bring the team through cycles of discussing high level requirements, diving into the details when the team needs to, and then pulling everyone back up to the high level. Get comfortable with letting conversations take place until you cover the topic just sufficiently to create a shared understanding.
A parking lot or other lightweight ways of capturing thoughts and ideas can help you rein the group back in. This gives the group a level of comfort that their comment or idea will not be lost. Of course, you’ll need to eventually go back to that topic when you need to.
Listen to the full episode to hear all of Barbara’s tips and advice on succeeding with requirements in an agile environment.
http://traffic.libsyn.com/masteringbusinessanalysis/MBA073.mp3
Z
Your Homework
Keep asking yourself if what you’re working now needs to be done perfectly or if you can let go of some of that perfection. Work to understand what level of detail is needed to achieve the desired outcome and what value it provides.
Links mentioned in this episode:
Barbara Carkenord
Director, RMC Learning Solutions
Barbara is the Director of the Business Analysis Practice and Co-Director of the Agile Practice at RMC Learning Solutions and has over 30 years’ experience in business analysis, project management and software development. Barbara is one of the founders of the business analysis profession; authoring books, articles, presentations and creator of several business analysis training curriculums.
Barbara earned an MBA from the University of Michigan and holds several industry certifications including CBAP®, PMI-PBA®, PMP®, and PMI-ACP®.
Thank you for listening to the program
To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes.
Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.
The post MBA073: Agile Requirements – What’s Different appeared first on Mastering Business Analysis.
Our TOPPODCAST Picks 
Stay Connected
