Do you have a people and process problem?

You've hit on a common pain point in software development, especially when dealing with business stakeholders and requirements gathering. It sounds like you're struggling with a lack of clear ownership and detailed requirements, which leads to your team constantly playing catch-up. Here's a breakdown of the problem and some potential solutions:

The Core Issue: The fundamental problem is a gap in communication and responsibility between the business stakeholders (who own the feature) and the development team (who builds it). The business side isn't providing the necessary level of detail, leaving the development team to make assumptions, which often leads to rework and delays.

Who's Responsible? While developers can help elicit requirements, the ultimate responsibility for defining the business rules and specifications lies with the business stakeholders. They are the subject matter experts and understand the intricacies of the feature. However, this doesn't mean they have to do it alone. It's a collaborative effort.

Why This Happens (and why it's hard):

• Lack of Time/Resources: Business stakeholders are often busy with their day-to-day jobs and may not have dedicated time for detailed requirements gathering.

• Unclear Process: There might not be a defined process for how requirements are captured and communicated.

• "I'll know it when I see it" Mentality: Some stakeholders struggle to articulate their needs upfront and rely on seeing a working version to provide feedback. This leads to iterative development, but without a solid foundation, these iterations can be very expensive.

• Technical Communication Gap: Business stakeholders may not be able to express their needs in a way that developers can easily understand.

How to Address the Problem:

1. Formalize the Process: Implement a clear process for requirements gathering. This might include:

   • Workshops: Facilitated sessions with business stakeholders to discuss and document requirements.

   • User Stories: A simple way to capture requirements from the user's perspective ("As a [user], I want [feature] so that [benefit]").

   • Acceptance Criteria: Clearly defined conditions that must be met for the feature to be considered complete. These should be testable.

   • Documented Business Rules: Explicitly define the rules that govern the feature's behavior. These should be clear, concise, and unambiguous.

   • Wireframes/Prototypes: While you're doing some wireframing, ensure they are used to validate requirements, not just as a starting point. Interactive prototypes can be even better for getting early feedback.

2. Assign Roles and Responsibilities: Clearly define who is responsible for what. The business stakeholders are responsible for providing the information, and someone (a business analyst, product owner, or even a developer with the right skills) should be responsible for documenting it.

3. Train the Team: Train both the business stakeholders and the development team on the requirements gathering process. This will help everyone understand their roles and responsibilities.

4. Use Visual Aids: Diagrams, flowcharts, and other visual aids can help communicate complex business rules more effectively.

5. Iterative Approach (with guardrails): While you want to avoid endless iterations, an iterative approach can be beneficial. Focus on building a Minimum Viable Product (MVP) first, get feedback, and then iterate on that. However, each iteration should be based on clearly defined requirements and acceptance criteria.

6. Prioritize and Focus: Don't try to boil the ocean. Focus on the most critical features first and get them right.

7. Communication is Key: Establish regular communication channels between the development team and the business stakeholders. This will help to ensure that everyone is on the same page and that any issues are identified and addressed early.

8. Escalation Path: Have a clear escalation path for when disagreements or roadblocks occur. This will help to ensure that issues are resolved quickly and efficiently.

9. Empower the Product Owner/Business Analyst: If you have a Product Owner or Business Analyst, make sure they are empowered to make decisions and that they have the support of the business stakeholders. They should be the bridge between the business and the development team.

Key takeaway: This is a people and process problem, not just a technical one. By focusing on communication, collaboration, and clear roles and responsibilities, you can significantly improve your requirements gathering process and reduce the amount of rework. It won't happen overnight, but consistent effort will pay off.