Years ago I used to host a study group for new business analysts in our organization that were just transitioning into our agile practice. One of the very first things we would talk about was what agile was not. For all the reality of agile, there are many, many myths particularly when it comes to requirements and the work of the business analyst. In this post, I tackle some of the most prevalent ones.
#1 Nothing is documented in agile
This myth goes something like this: “agile is fast because you don’t have to document anything.” Because agile methodologies don’t prescribe types of requirements to develop, I have found that many IT organizations interpret this to mean there are no requirements in agile. All of the agile frameworks support documented requirements of some sort. The difference from traditional methods is that the agile documentation is lightweight with a preference for executable requirement models over text-heavy specifications. More importantly, only what is needed to produce the story or feature is documented and nothing more.
#2 Stories don’t need requirements in agile
Agile lingo is heavy in the use of the word “stories” and light on the use of the word “requirements” in my opinion. I think the myth here is that stories are the only thing from which code is written and test cases are executed. This is misleading. Stories are simply placeholders for conversations about a feature or need to be developed. They are not intended to be requirements. The idea is that there will be collaboration to provide details about exactly what will be developed. That further detail is found in a requirement artifact. The nature of that artifact will be less like text-heavy, upfront requirement documents typical of traditional processes. Instead agile artifacts will incorporate models and diagrams that make requirements come alive for the business and IT team members. Still, that doesn’t mean that the model gives all the detail. Other artifacts, like system configurations, rule tables, error messages and non-functional requirements, must be built in order to develop a cohesive product. These artifacts will take the form of more standard requirement artifacts.
#3 Requirement management is not needed in agile
So if stories require some level of requirements then, yes, requirements on agile projects must be managed. But the term “requirements management” comes with its own baggage because of its association with traditional and waterfall methods of collecting requirements. I’m not suggesting detailed Word documents or complicated requirement tables. There is a need for being intentional about what artifacts will be created, how they will be linked together (traced) and what systems will be put into place to keep them updated, accurate and reflective of what is being built as it is being built. This takes a little creativity when the basis of the artifacts is lightweight and iterative, meaning small pieces will be developed over time. Someone – like a Lead BA – will need to have a big picture for how they will evolve over time and how to manage the versions of those artifacts. This cannot be ad hoc or left to the discretion of the BAs on the project (unless, of course, there’s only one BA). Requirement artifacts are assets, just like the working code or an automated test bed, that have a cost to build; therefore, how they are created and managed must be planned in agile projects.
#4 Agile teams don’t have business analysts
While it’s true that agile methodologies don’t have a specific role called “business analyst,” business analysis is critical to the success of the team by helping to ensure that value and quality are delivered for the customer. For example, the business analyst may:
- plan and facilitate collaborative requirements workshops
- act as the product owner if one is not or cannot be available
- manage requirements to ensure completeness, correctness and consistency in delivering towards the requested feature
- coach and train others on the team to create requirement models
- perform other functional tasks needed by the team such as facilitating sprint ceremonies, writing the acceptance criteria, testing or triaging bugs
Analysis work may be performed by a BA or can be incorporated into the work of other roles on the team; however, analysis, elicitation and documentation of requirements must happen to ensure the right product is built.
#5 Product Owners do the business analysis in agile
The role of the product owner is the voice of the business and is the ultimate decision maker for the product. This role may perform some business analysis activities. However, while they may have a good handle on the needs of the business, they rarely have all the skills needed to perform business analysis. Business analysts can pair up with Product Owners to ensure that stories are fully fleshed out and more detailed requirements are developed when needed.
In addition, many times Product Owners may not be fully allocated to the project. Business analysts can fill the Product Owner role when necessary to keep the work moving. They may also be able to perform other Product Owner functions such as making some decisions, adding to or prioritizing the backlog, or working directly with the customer when the agile team has questions.
I’m sure you’ve heard some myths about requirements or business analysts in agile. Share your myths and let’s debunk them!
[…] For more on listening, check out my post The Difference Between Hearing and Listening. […]
[…] happens to us all. You’ve prepared for your workshop, sent out the pre-work and then your participants aren’t ready…
[…] the prior posts we’ve put together our agenda and identified our participants. In this post, I discuss how to…
[…] the prior posts we’ve put together our agenda and identified our participants. In this post, I discuss how to…
[…] that has been cobbled together to solve the symptoms of a problem. I wrote about this in my post…