How to find your team’s goldilocks requirements

Business analysts often struggle to find that balance between too much information in backlog items, and not enough. The answer, work with your team to find the amount of detail that’s just right.

If you regularly work with product teams in a business analyst or product owner role, I’m going to guess that you’ve struggled to figure out the proper level of detail for your requirements.

It didn’t matter if you wrote epic requirements documents (which were probably too long and didn’t have the right detail) or a bunch of backlog items (As A, I Want, So That generally doesn’t cut it). People on your team didn’t have the information they needed to build a solution, let alone know if they were creating something that solved your user’s problem.

So to address the situation, it’s helpful to put requirements in perspective. For the purpose of this discussion, I’m going to assume you’re working in an iterative fashion and your team organizes work into backlog items (the generic term I choose to use instead of user stories).

Requirements build shared understanding

For starters, requirements are a means to an end. They ultimately are one way to create shared understanding among the people who are trying to solve a problem through building some software.

Depending on the nature of requirements they either help define the problem you’re trying to solve, or describe a solution you’re planning to build.

To make sure requirements are successful in creating shared understanding, they need to be in a form that makes sense to the people who need to have that shared understanding - the makers (developers, designers, testers, etc.) who are going to build the solution. In other words, your product team.

So if you want to know the right level of detail for your requirements, ask the people who are going to use them - the people on your product team.

The definition of ready

A technique i’ve found particularly helpful for guiding that conversation is the definition of ready. You can think of it as an agreement on the “necessary information” a backlog item needs so your team can start building that portion of your solution.

As with a lot of techniques I share, the value is in the discussion involved in coming up with the definition of ready because it gives you a chance to understand what information your teammates think might be helpful and for you to consider what’s reasonable to pull together for every backlog item.

Your definition of ready is a handshake agreement, a set of guidelines if you will, that describe what your team thinks would be helpful.

You should definitely be prepared to revise the definition after you have some experience of fleshing out some backlog items and the team has experience referring to them to build pieces of the solution.

You may find that you’re putting more information than necessary in the backlog items, or your teammates may find they still had to ask a lot of questions. The key here is reflect on that experience and adjust your approach.

Backlog Refinement is a team sport

There are of course a variety of ways to structure your backlog refinement. I’m not going to dictate a specific approach, as long as whatever approach you use works for building a shared understanding among your team.

In some teams that means that multiple teammates are involved in crafting backlog items from the very beginning. Mike Watson observed that your developers can steer you right if you involve them early and often.

Involving your dev team early and collaborating with them throughout the process ensures that the work is aligned with business goals and built in the most effective way possible. You’ll save time, reduce unnecessary rework, and build a better product for everyone—especially the user.

Other teams find it works for one person (usually a business analyst or product owner) to write an initial version of the backlog item and then get together with other teammates to review and revise.

Experiment with different approaches to find what works for you and your team. If you come up with a particularly novel way to build shared understanding through backlog refinement, I’d love to hear about it.

Determining the right level of scope

Another aspect of too much or not enough detail in requirements is the scope of those requirements. By scope I mean how big of a piece of the solution are you trying to describe with a single or set of backlog items.

Alex Debecker identified seven signs of scope bloat he uses to flag a backlog item thats too broad. The signs are worth checking out to see if you’re trying to accomplish too much with a single backlog item.

If you remember nothing else

It’s highly unlikely that the first backlog items your team uses will resemble the backlog items you use six months to a year down the road.

It’s ok to have some fits and starts when you’re trying to figure out the right level of detail for your backlog items. They key is to work with your team to figure out the information they need and format in which it’s most helpful for them.

It’s not important that you get it right from the beginning as long as you eventually land on something that works for your team.

Thanks for reading

Thanks again for reading InsideProduct.

If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, let me know.

Talk to you next time,

Kent