It seems each year it gets worse and worse—BAs have WAY too much to do! They can’t say no and can’t ask leaders to slow down the flow of requirements work.
The backlog grows bigger and bigger, and teams get further behind every day. It’s impossible to catch up.
I am going to write something that might shock you or might make you upset. It may also be a welcome confirmation.
YOU ARE PROBABLY DOING TOO MUCH – TOO MUCH OF THE WRONG THINGS!
Yes, I mean it. Most teams, when I really dig into their work and the dynamics of all the work on their plate, are doing too much.
Too much in terms of:
- Too much detail in their requirements, usually technical details for pages and pages; when they need to focus on user goals, decompositions, rules, and data.
- Too much scope, yep… most solutions need far less scope than we actually implement.
- Too much work, most of the requests that come in don’t NEED to be done, and most are not as urgent as we are led to believe.
Here’s how it typically happens—WARNING—get ready for the vicious, head-spinning cycle…
Requests come in from business/operations teams, and they are simply that, requests. Teams that simply fulfill the requests, without analyzing them, end up missing pieces that trickle in as 5 more requests later. The snowball of craziness continues creating an ever-growing backlog of what seems like endless requests. It gets worse when the team and BAs work to write “tech specs” for each request, the team looks at tech specs and judges if it is feasible, not if it should be done. And, now no one is questioning the user point of view or the “WHY” part of the requests. Everyone is in “execute” mode.
Now back up…what if we asked the right questions before we start executing the “requested” technology update? Would our requestors have the answers? In most organizations with giant backlogs, the people making requests struggle to answer very important questions like:
- What business problem we are trying to solve?
- What does success look like?
- What would happen if we don’t do it?
- Who will be impacted by the request?
- What is the end-user’s goal?
When our requestors can’t provide confident, meaningful, value-grounded answers to these questions, we have 2 choices:
Choice 1) We ignore the fact that the business case is murky. We tell ourselves the requestor knows what they need and it will be faster and more successful to just get ‘er done without asking questions.
Choice 2) We stop, think about it, formulate some good questions, identify the right person to ask the big questions, and have the conversation.
If you go down the path of choice 1, you are working too hard and not getting enough done. You are clearing requests, but nothing really gets DONE. Without fully understanding business and user needs, you are generating lots of rework. Repeatedly choosing this path makes your backlog grow exponentially and creates the vicious, head-spinning cycle that puts you in a constant state of fire-fighting.
If you so bravely take choice 2, congratulations! You are on your way to working less and getting more done. This is how we influence without authority! You’ll get half (hopefully more) of the work paused until there is a compelling reason to work on it and it can be defined in a way that will not cause rework later.
I have heard many say, “Oh I can’t do that, my leaders tell me just to get it done! If I ask too many questions, they will feel like we are stalling or going backward. They will get even more frustrated.”
Let’s talk about that for a minute. I think we have a great misunderstanding about what “get it done” means. When BAs hear “get it done,” they tend to think about how fast they can get requirements to developers. They reduce or even skip the elicitation and analysis work.
But when I talk to leaders, their definition of “get it done” is more like “get it done right” or “move our organization forward.” Leaders tell me they wish their BAs would ask better questions and work on the right stuff. They wish BAs would analyze and build relationships that influence others to carefully select (with a clear set of value- and user-driven requirements) which items are the most important.
This is an acquired skill that can’t be learned overnight! You can’t do it with a template. You can’t do it with edicts or procedures. It requires focus—concentrated focus to get the right conversations going.
But it is well worth it–BA work will be fun again!