Skip to main content

2 Requirements Tasks You’re Probably Spending Too Much Time On

Can you guess the number one question I get from requirements leaders across the world?

Whether their team is agile, traditional or hybrid, whether their team has 2 members or 250, whether they are creating cutting edge products or maintaining legacy systems, their primary concern remains the same: “How do we get requirements done FASTER?

Despite great intentions, leaders react to this time crunch pressure in a way that actually decreases the speed and quality of their requirements process. The “Get it done faster!” command tends to shift the team’s focus—discussion, collaboration, and true analysis time gets cut short and completing detailed requirements documentation (BRDs, SRSs, use cases, user stories, etc.) takes priority. I see a lot of BA teams struggling with this constant pressure between deadlines and quality.el

Related Article: Want Faster Requirements?  Build Them Like a Snowman!

In this battle between quality and deadlines, many give into the deadline pressure. So, they jump to documentation without much dialog and analysis and use the document review process to elicit and analyze. You might think this makes sense, especially in well-established organizations, but it will NOT help you speed up your requirements process.

When teams minimize planning, elicitation and analysis, and spend most of their time documenting and reviewing requirements, the process will be long and painful, and teams will miss opportunities to boost value to end users.

So, how is your team doing? What’s the right mix of requirements activities to maximize speed and quality?

Make a pie. Estimate the % time you are spending on these five requirements activities: planning, eliciting, analyzing, documenting and reviewing. Does it look like this?

angela august

If your time allocation looks like this, I’m sad to report you are probably doing a great job documenting something that will cause scope changes, rework, and may even result in more problems than value; adding to the ever-growing backlog.

We need to spend less time documenting and reviewing! Documenting and reviewing are low impact forms of communication and collaboration. This means they are not meaningful to the type of thinking requirements work entails. Documenting and reviewing use parts of our cognitive processes that do not help build consensus, do not help connect the dots, and do not inspire critical thinking and progress in our solutions.

So, stakeholders leave meetings drained. Then, hours or days later, attendees think of changes and ideas outside the meeting. They dialog with others and then bring “last-minute” changes to the team. This results in a slower process overall. It takes LONGER to get the same result when teams minimize planning, elicitation, and analysis.

In requirements, we need to shift mindsets and practices to get the critical elicitation and analysis dialog and modeling completed before documenting and reviewing. This will result in quicker meetings and reviews of requirements.

A better mix for all teams (agile, traditional and hybrid) looks something like this:

angela august 2

Documenting and reviewing, when everything else is done right, should take less than 5-10% of total requirements time. We need to guide stakeholders through the process, a process we own as BAs. We must advocate for the importance of planning, elicitation, and analysis and share the risks of reducing or skipping these activities.

Here are a few benefits and risks you can use to help your team or your stakeholders transition to a faster and better requirements:

Requirements planning is about understanding the context, problem, goals, risks to value, and requirements approach. Even agile teams need to plan. It’s the foundation for building the right solution the right way and ensuring the requirements process is meaningful and valuable.

What happens if we reduce or skip it?

  • The team does not understand the WHY of the process or the problem.
  • The team cannot anticipate what is coming next.
  • Team members do not understand how their piece fits in the puzzle or how their piece impacts the rest of the pieces in the puzzle which causes rework.
  • We over or under engineer the solution.
  • Progress is chaotic and slow while team members keep circling back to try to understand the items above.
  • The organization will waste time and money solving the wrong problem.
  • Trust breaks down between teams.

Requirements elicitation is about getting stakeholders to create a shared understanding of the future state. Elicitation is an iterative process that helps stakeholders move from the big picture down to the finer details. We use models and diagrams to help stakeholders understand processes, workflow, data, user experience, rules/logic/decisions, exceptions, non-functional requirements, etc. Even seemingly straightforward enhancement requests require elicitation to determine if it’s the tip of an iceberg.

What happens if we reduce or skip it?

  • The team will not understand what the future state looks like, how it delivers value or how it will impact them.
  • The requirements will have gaps as stakeholders assume their request covers more than stated.
  • The team will miss innovative ways to bring value to the end users.
  • The organization will waste time and money fixing the solution/product after implementation.

Requirements analysis helps us understand the impacts of the future state and the people, processes, and technologies are affected. Again all teams, agile and traditional, need to use analysis activities to get the requirements right and build something useful.

What happens if we reduce or skip it?

  • End users will not be prepared to support or use the solution.
  • The team will not find requirements gaps, which will generate issues at implementation and require significant time and effort to address.
  • The team will not maximize the solution value. End-users will not be satisfied with the solution and will request major enhancements or simply avoid using the solution.
  • The organization will waste time and money building the wrong product/solution.

When planning, elicitation, and analysis are done well, documentation and review are simple and speedy.

The overall goal of planning, elicitation and analysis activities is to create a shared understanding of the various areas of scope, value, and impact. To simplify even further, we get everyone on the same page, so we don’t waste time creating and reviewing irrelevant documentation.

When we have shared understanding it’s easy and quick to put all the pieces into a user story with acceptance criteria, or a requirements document, or a tool. The review/sign-off process becomes quick as well because the team already understands context, scope, value, risk, etc.

How do you minimize time spent on documentation and review? Please share your tips in the comments below.