For most of us, we are adjusting to a new remote work environment. Yet, it seems like as we still have way too much to do! Keeping pace with leadership and project owners is vital to carrying the process forward however setting good boundaries and knowing when to say when is equally important. That’s why making good choices on your requirements approach can help rather than hinder the process. Read on for more helpful information on setting boundaries and making good choices. Like our moms told us too!
Radical acceptance. Yes, the backlog grows bigger and bigger, and teams it seems like get further behind every day. Accept that there is not a perfect world where the backlog will ever be 100%. Not everything in the backlog actually needs to get done! Stop striving for something that is not achievable. And I am going to write something that might shock you. It may also be a welcome confirmation. Nobody expects you too! Tada! How liberating! It is time to Prioritize and Make Good Choices.
First, what are some ways to make requirements a more efficient process:
- Don’t put too much detail in the requirements, technical details for pages and pages are not needed, that is for the technical team to collaborate together and sometimes with you on. Focus on user goals, decompositions, rules, and data.
- Too much scope, yep… most solutions need far less scope than we actually implement. Strive to minimize what is needed to maximize the value. What stakeholders ask for isn’t often what they actually need
- 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. Understand the user’s pain and need, then work with them to prioritize what goes ahead of what, not just high, medium and low.
How does this happen? Here’s how we fall into the rabbit hole.
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 five more requests later. The snowball continues creating that creeping backlog of endless requests. It expands when the team and BAs work to write “tech specs” for each request, the team looks at tech specs and judges if it as feasible, not if it should be done. And, now no one is questioning the user’s point of view or the “WHY” part of the requests. Everyone is in “execute” mode.
Prioritization as a Function
Now back up…what if we asked the right questions before we start executing the “requested” technology update? Would our requestors have the answers? If we present the options as choices we are guaranteed to create a culture of choice-making and prioritization. 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-based answers to these questions, we have two choices:
- 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.
- 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 choosing one, you are working too hard and not getting enough done. You are clearing requests, but nothing really gets accomplished. Without fully understanding business and user needs, you are generating lots of re-work. Repeatedly choosing this path makes your backlog grow exponentially and creates the innocuous, head-spinning cycle that puts you in a constant state of fire fighting. Didn’t someone once say that was the definition of insanity?
If you so bravely take choice two, 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 create more work later.
The Reality of Good Leadership
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.” Choice two is really about managing up. Good leadership will value these efforts and you will be respected for it!
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 for 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. Practice making good choices, practice asking the right questions, even if it feels uncomfortable at first. Growth occurs outside of our comfort zone. Making the right choices will result in a team that prioritizes requirements.