Product Backlog vs. huge features

Question

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?

Answer 1

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.

Answer 2

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.

• Bring together individuals with the skills to help solve the problem
• Continuously throughout the effort work with the customer to understand the problem and how effective the emerging solution is
• Provide the support, training, resources, other staffing, etc. needed
• Work in small iterative cycles to increment the solution as more is learned and the current solution is evaluated

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.