Agile development emphasizes effective communication and learning through continuous feedback. Backlogs are tools to manage the discussion about the features of an evolving product. They are simple in form but demanding in content. Here are a few challenges.
1. Too detailed
By writing detailed development blue prints like traditional requirements specification, the product owner wastes time and takes up space from the creativity of the development team. The things in the backlog are comparable to the product breakdowns presented in traditional project plans. They are intentionally incomplete.
For example, a software developer will probably know what kind of program logic is needed to implement the return, OK, add, change, and delete buttons in the interface. In this case, no separate user stories are needed to describe them in the backlog.
2. Too big, projected too much
A Backlog with several hundred or even thousands of items predicts the work of the development team for years to come. It is premature to include things that are not timely in the backlog. It is not even certain that they will ever be done.
3. Business benefit, metrics missing
In order to prioritize the backlog, it is important to understand why the product has these very features. Cost-benefit calculations must be possible at least at a rough level. For example, a user story: As a marketing representative, I want our website to use cookies so that we can target our sales and marketing efforts well to our customers. From this, we can continue the debate about whether the use of cookies is good business.
4. The “why” of the user story is wrong
For example, the user story: “As a customer, I want to use Digital Service X to save nature” probably describes the need less than “As a business owner, I want our customers to use Digital Service X to save 10% on our costs. Adding metrics often reveals whether we are doing the things that are actually required for a product to succeed.
5. Not Concrete, too abstract
The need for business alone is rarely enough. The development team wants to know what they need to produce. For example, what should the development team do to implement the user story “As a company owner, I want a strategy to secure growth in shareholder value in the years to come”?
6. Full page user story
The user story format is not suitable for all situations. Its use is not mandatory. For example, complex software logic or visual appearance is difficult to describe in a single sentence. The backlog can be augmented with various diagrams, sketches and calculation rules.
7. Architecture is missing
The structure of the backlog describes not only the work in progress but also the architecture of the product. In a good architecture and backlog, components (especially themes and epics) can be built, published, and replaced independently. A spaghetti code is easily generated from a ticket list.
8. No increments are generated
A traditional requirements specification often describes a large number of components that are integrated together just at the end. An incremental and iterative model of agile way of working where we have a constantly functioning and evolving product requires a backlog that supports that. For example, since the user interface and the backend are not built separately, they are also not separated into their own items in the backlog.
9. No discussion with team and users
Because the backlog is intentionally incomplete, the product owner, users and developers should actively discuss with each other. Understanding of the product is not conveyed through the sending of documents and emails but through the interaction between individuals.
10. No feedback: POC, alpha, beta, MVP
When writing a backlog, keep in mind that the product develops piece by piece. The product is made available to users and customers for evaluation at the earliest possible stage. It is better to fail with a proof-of-concept than at the end of an expensive R&D pipeline. The backlog tells whether the feature will be published in POC, alpha, beta, or later.
11. No changes, no reviews
The backlog describes the part of the product currently under construction. It differs from the project plan in that it is not frozen at the start of the project. Instead, the product is intentionally improved through customer and user feedback. The review is an event where the Scrum Team discusses the future of the product with stakeholders.
12. General definitions for the definition of done
General specifications such as non-functional requirements, security policy, and user interface standards are described in the definition of done. In this case, they are not repeated unnecessarily in the backlog.
13. The division of labor into teams is not communicated
The structures of the development organization, product, and backlog tend to match each other so that dependencies can be managed within each team. Strong planning in advance or large inter-team meetings have not proven to be a fast enough and interactive way to communicate.
14. Platform specific teams
It is difficult for a product owner to optimize the value of a development organization’s work if it consists of knowledge islands. In the backlog, platforms such as Android, iOS, and Windows are only considered at the sub-level, which belongs to one team.
15. Double work, missing parts
The backlog, open to everyone, spreads the overall picture of the product so that each feature is built exactly once. In terms of component reuse, the agile world is opportunistic.
Traditions and organization of work are the root causes of the above. The consequences unfold when you take into account the emergence of understanding and the changing needs as development work progresses.