There is no time to have something more than User stories

Note, that all the above doesn’t relate to start-ups where a path of trial and error is accepted as nobody knows what the result is expected. All the above is about projects, where a client or Product owner has a particular vision of the product.

So…

If your requirements consist only of user stories because there isn’t enough time, I want to tell you that it’s not about time 🤗.

It’s not about time. It’s about a norm. What are the standards for a BA’s work and its quality? Because everything that is considered valuable and necessary finds the time.

What is your internal standard?

To jot down the backlog from what you’ve heard or to first analyze what you’ve listened to (techniques) and ask the emerging additional questions?

To go story by story and then go back because something was overlooked, or to build at least a high-level complete picture and identify dependencies?

And one more nuance about time. The idea that quality takes more time is a superficial impression.

In fact, as a BA, you might indeed spend a bit more time initially (we’ve discussed before that techniques take time because you’re not used to using them. Once you start thinking with these techniques, it won’t take long, but it will be at a completely different level), but then both you and the team save a lot of time on communication because there are fewer questions, and you don’t waste time going back to analyze user stories that were returned to analysis. As a result, development proceeds faster. This is important when a project has fixed deadlines and a budget.

I have an example from my experience where we had two teams on one project. The first team worked using the “Throw in some stories” approach. I worked using the analysis-first approach, where stories are the result. I took one sprint for analysis for each new feature, resulting in a complete picture of the feature with roles and their goals, processes, scenarios, status models, and data references. There was also a decomposition into stories, but the stories themselves were not yet created.

With all this information, I would go to the team. They could see the whole picture and, during this meeting, they would come up with solutions that could be reused in several stories. They would then work on one story, understanding what would be in the others and what this functionality meant for the feature as a whole.

As a result, our team implemented features twice as fast as the first team, without overtime, and moved on to the next ones. The first team kept struggling with the same features and constantly had to rework them.

To conclude, don’t fall for the trap of thinking you’re wasting time, because otherwise, the whole team will end up spending much more time.