Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
I am designing and documenting a product with agile process. When I write user stories to add them to the product backlog, I found myself in a complex and huge features.
Should I write these features on a product backlog and order them according to their priorities or they will confuse my plan so they may deviate my product from what I expect?
My personal perspective from having worked in agile for a few years, is that you really shouldn't fear a large backlog (to a point).
If you are writing self-contained user stories, each of which is effectively complete in and of itself, then you really only need order them by priority and things shouldn't get more "complex" as new stories are added to the list, even if the list is huge.
I find that when people start thinking the backlog is "too big", what they actually tend to mean is that its full of vague, outdated, irrelevant or confusing items, and they've lost the ability to think of it simply as a list of self-contained piece of work ordered by priority, because it's evolved into something else. Something it shouldn't be.
Often this manifests as attempts to organise the backlog into epics or even sortof "category sprints" (often called things like miscellaneous or "needs refinement"), but this only hides the problem, adding even more complexity as the underlying problem with inappropriate things going into the backlog continues, and things hidden in these category sprints get duplicated.
This might not be you, but if you're finding that the above sounds familiar, you might want to consider that the fact you feel you cannot use the backlog for its process indicates that, for some reason, your organisation is not using the backlog for its intended purpose and this is producing confusion and disorder.
tl;dr
Should I write these features on a product backlog and order them according to their priorities or they will confuse my plan so they may deviate my product from what I expect?
Do not spend much time creating details. Continuously collaborate with the customer and those developing the solution.
What is your understanding of the term agile? There is no single agile process. There are processes, frameworks, methodologies, frameworks, etc. that uphold the philosophy described by the four values and twelve principles of the Manifesto for Agile Software Development. Notice that "agile" is only used three times with all of them as an adjective to describe and not as a noun to name.
With that foundation, there are several red flags in the phrasing of your question. The problematic paradigm of attempting to understand it all up front through big design and a lot of documentation (traditional plan-driven project management) is the reason that "uncovering better ways of developing software" resulted in the Manifesto.
For additional information see The Scrum Guide and Extreme Programming. The paper, Managing the Development of Large Software Systems, that somehow lead to the Waterfall SDLC model was apparently never read beyond figure 2.
