Worldwide Locations
Abstract
The principles in this white paper help you introduce greater predictability into your own Agile requirements activities, both individually and across your organization. As you start to apply these ideas and pose these questions, you'll likely see certain patterns emerge that will help you establish your own set of practices that make Agile work for you.
Sample
Introduction
By now, you're no doubt familiar with the statements below:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
- The Agile Manifesto
These words led to a multitude of discussions, leaving business analysts (BAs) often wondering, "What exactly is a BA's role on an Agile team, anyway?" Granted, working software is more important than comprehensive documentation.but just how complete and descriptive does the documentation need to be? And how much detailed analysis are we talking about? A common answer is: "Just enough to get the work done."
"Just enough" is a common refrain in Agile, as in just enough documentation, just enough analysis, just enough oversight. Practically speaking, what does that mean for a BA? The phrase, "just enough" is subjective-how do you flesh it out and make it practicable? Answering that question can be tricky enough within the confines of a team-but how do you pin down what "just enough" means as you scale across an organization?
There's no International Organization for Standardization (ISO) standard at play here, and a healthy dose of independent thinking and individual discretion is advised. But you can start by keeping the following principles in mind:
1. Every project needs some kind of requirements documentation, whether formal or informal.
2. Planning and structure help streamline requirements.
3. "Just enough" applies to communication, too.
4. Look at the other documentation your team is producing.
5. User stories are medium-level requirements. Sometimes that's enough. Other times, it's not.
6. The greater the consequences of failure, the more you need up front analysis and documentation.
7. Greater regulation = more documentation.
8. Higher integration = more documentation.
9. Ask your stakeholders.
Let's dig into these one at a time.
1. Every Project Needs Requirements Documentation
In the first heady days of Agile, there was a lot of talk about no longer needing a specialized BA role. The idea was that everyone on the team would be practicing business analysis-communicating directly with the business, abstracting requirements from stated needs, and working collaboratively to build out a solution that met those requirements beautifully.
In practice, this led to varying degrees of success. Some skilled teams have been able to execute effectively over the long term without having a formal BA on board; others have found that their results improve dramatically when a BA joins the team. But there's also been an unintended side effect: the occasional crowdsourcing of the BA role was in some cases conflated with the idea that requirements documentation itself was unnecessary and obsolete.
If my manifesto-reading skills are as good as I think they are, that was never the point of Agile. Remember, Agile's foundational statement acknowledges the value in good documentation-it just points out the fact that there's less business value in docs than in working software. True enough.
So, requirements do, in fact, have a conceptual home in Agile. Keep in mind that working software is going to be built on some sort of documentation describing an underlying business need. In other words. requirements documentation.