During agile training sessions, the most common question I get is, “Can you PLEASE just tell me what I need to document as an Agile BA?”
So, let’s clear up this up once and for all!
The answer is NOT simply user stories and acceptance criteria, or a traditional requirements document. Agile is just not that simple. This answer would focus on the wrong thing—output. Instead of focusing on output, it’s the outcome and the path you take to get to the outcome and outputs that’s important.
The reality is, your job as a BA isn’t to document, and it never has been! Seriously. Even when doing waterfall or traditional approaches for requirements, the BA role is about facilitating decision making and facilitating future state discovery. Documentation is the output of all of this. Yes, documenting is part of the job, but it’s not the goal of the business analyst role, no matter what approach the team is using.
Start With The Why
I am not a “no documentation” zealot, but I am passionate about ensuring that what we create is valuable. Let’s ask ourselves two questions about the documents we create: “What is the purpose of the document and why is the organization willing to pay for it to be created?”
Requirements-related documents cost organizations lots of money, so we need to be able to answer these questions to get the right content documented. We want to avoid wasteful documentation as well as avoid the endless spin created by team dynamics that need a memory of what was discussed already.
When teams transition to agile, they often try to make a concentrated effort to look at documenting less; and this is a good thing to evaluate in the spirit of cutting out waste and focusing on value. When teams are going through this I often see a lot of wasteful documentation teams say THEY MUST have.
Here are the arguments I frequently hear for excessive documenting on agile teams:
I will provide my perspective on these arguments, but first we need to cover three important pieces of a healthy agile mindset and environment.
Apply Agile Principles And Working Memory Concepts
An agile approach enables teams to document less and increase speed while reducing costs. Here are the three agile principles that help teams reduce documentation:
It all comes down to “working memory” and leveraging the working memory of the team to reduce the dependence on documentation.
When a team has Limited WIP, they only work on one or a few things at once. There is less to remember because there aren’t days or weeks between discussions while you work through dozens of topics. With this intense focus, a small cross-functional, co-located agile team has enough working memory capacity to track details with minimal documentation. When a team is leveraging these principles, it feels strange and wasteful to stop and document unless the team agrees it is needed to help them move forward.
Working memory is a key to the puzzle and working memory is maximized when there is limited WIP, small teams and co-located teams. If your organization compromises on any of these, then the working memory of everyone is compromised. Work slows down while teams document to help them remember as they switch between too much work in progress.
What Should Be Documented?
Documentation in agile is “living” and should be updated as the team need to update it. Think of it as a living asset the team uses that grows, gets pruned, gets trimmed and grows some more.
A small, cross-functional team with limited WIP, should document the following:
Remember to keep documentation as simple as possible. Choose a format and level of detail that allows change and delivers just enough value to keep the team moving forward in the right direction.
What About Compliance, QA, Vendors, Offshore Teams, Training, Etc?
OK, back to all those arguments teams use to rationalize excessive documentation. When you focus on limited WIP and small, cross-functional, co-located teams, these are the agile-minded responses.
Essentially, I’m asking you to adopt an agile mindset and advocate for limited WIP and smaller teams that reduce the need for documentation, reduce costs and accelerate product/solution delivery.
If your organization has compromised these principles, then working memory challenges are likely driving your teams to document more. That is okay, as long as the team and organization realizes the value of the document and is consciously choosing to slow down outcomes and results due to the choice of compromising the agile values.
Remember that your role as an agile business analyst is not about documentation. It’s about facilitating good and timely decisions, and guiding stakeholders to discover a future state that delights the end user.
Guest Post by Angela Wick, BA Squared
Your details have been submitted and we will be in touch.
Your details have been submitted and we will be in touch.