Shashi Velur’s blog

Backlog is used for prioritizing, tracking and communicating the work (work items) to be done in the future Iterations/Sprints.

There may be multiple teams working from one backlog, but if there are more than 3-5 sprints worth of work items for all teams working on that backlog, then I consider that to be huge. I have noticed that if the product owner is not careful, the backlog can grow and become really huge.

This is not good for several reasons:

• It is depressing for the everyone on the team. This may lead to a belief among team members that this is a case of a large product with not enough resources.
• Priorities change - It is a waste of effort for the product owners to endlessly sort through the work items in the backlog every Sprint to come up with a list of stories for a Sprint.
• Some of the items in the backlog are never worked upon even after months/years. In that case why spend effort prioritizing them?
• It is hard to react to change in the market conditions, when the teams are so focussed on possibly “stale” requirements in a backlog.

So, what are the possible causes for this?

1. Lack of clarity of product vision.
2. Disagreements between the product management and marketing about the importance of features. So, the “unimportant” ones (mostly due to disagreements) find the bottom of the backlog.
3. Product owners unable to decide on the “business value” and ROI on requirements in the backlog. This may be due to the lack of authority (to do so) or communication breakdown or just the organization culture itself.
4. Sometimes, for various reasons, a suite of products might have one product owner per product who do not necessarily agree on everything especially when it comes to the cross-product requirements.
5. Inadequate resources, unstable team, attritions, shuffled team members, not-so-well-performing teams, etc.
6. Treating defects as backlog items. Sometimes, a lot of medium defects are tossed in to the backlog.
7. Poor/Complex Technical Architecture - This means that the features get done much slower than estimated.

Technorati Tags: Agile, Agile Best practices, Backlog, large backlogs

I have come across several articles on the best practices for Agile/SCRUM.

I read this somewhere and really liked it:
There is not and never will be a list of “Scrum Best Practices” because team and project context trump all other considerations.

Here are 5 practices that may be considered as “not-so-agile” by purists. But, making the following changes to our Agile/SCRUM process actually made us a very effective Agile Organization..!

Dedicated Testers & Writer on the SCRUM Team:
This could be against the “No specialization” or “No fixed Roles” Agile principle.

Minispecs:
This could be against “use the working code as documentation”. We use MiniSpecs very effectively to document key requirements and design/implementation decisions in a concise manner.

Our SCRUM Master is our Sr. Director/Manager:
This is self-explanatory. Our Manager is actually a certified SCRUM Master with two decades of development experience. He demonstrates great balance.

Team members shared across teams:
We have a UI specialist and an Architect/Developer shared across 2 teams. I guess it might make sense to share the UI specialist. The Architect/Developer shared across teams has helped us immensely improve communication and to effectively sort out integration issues across the products in our Product Suite.

Multiple backlogs for the same product suite:
Okay. This one might be up for debate. Our Product suite consists of at least 5 products that have their own SCRUM Teams. There is also a Product Owner with individual Product backlog for each of these products. Also, there is a common backlog for infrastructure/common functionality.

Technorati Tags: Agile, Agile Best practices, SCRUM