Challenge in requirements capture & elicitation in Scrum team
Dear all,
I am facing a challenge in one of my Scrum Teams for which I'm working as a Scrum Master. This Team is very good at working together and solving customer & business team's problems through collaboration, communication & cross-functional mode of working.
However, the biggest challenge that we're facing is while trying to get the requirements/ problems or roadmap objectives from the business. The business team provides a yearly Roadmap of Objectives & Milestones to be achieved and then splits it into quarterly snapshots of the Roadmap (The roadmap itself gets evolved and updated quarter on quarter).
Post presentation of the Roadmap by the Business Unit Manager to the POs of the different Scrum Teams, its for the POs to follow up with the individual business stakeholders for the exact needs, specifications and other details of the individual objectives. The business stakeholders do not provide any BRDs/ PRDs for the PO to understand the exact requirements - everything is discussed orally between PO & the business stakeholder. On the basis of that, when the PO creates the User Stories and creates the Sprint backlog. Once the Team finishes working on those Stories, at the time of review, the business often comes up with discrepancies in the original requirement and say this is not exactly what I asked for. And then they demand the work to be re-done within the same User Story. This loop sometimes goes for 2-3 times because of which the Dev team gets really pissed off. Even the PO feels helpless as when she asks for the specifications, the business gives it orally and then they change their mind later upon seeing the review.
As a Scrum Master I am really struggling to be able to help my team in this situation. My Team is becoming irritated because of this day by day. What can be a way out of this situation? Can I ask business to provide PRDs, or rather provide sign off on their requirements, so that they do not go in loops as part of the same requirement point?
If it was actually possible to do any of these things successfully, then you wouldn't need Scrum. If it was possible to defer updating requirements quarterly, for example, then a Sprint would serve no useful purpose. If it was possible to somehow "sign off" on requirements, then no Product Backlog would be needed to hold an emergent body of work.
Humility is needed in this organization. They genuinely don't know. Moreover, this is OK and ought to be expected. The work is complex, it really is emergent. They might reasonably start to refine a Product Backlog months in advance of doing the work, but this is not capturing the requirements. It's the start of a conversation. Not knowing is not a failing. Insisting that you do know is.
Organizations love their certainty, even if it has to be faked, and that's the challenge you face as a Scrum Master.
The issue isn’t missing documentation - asking the business to "hand off" BRDs and PRDs is the wrong move IMHO. What us stopping you from bringing the people doing the work (i.e. the Developers on the team) into refinement sessions with the stakeholders?
Another issue seems to be that the Product Owner is acting as a proxy and Product Backlog refinement isn’t creating shared understanding early enough, so learning happens too late and shows up as rework.
If stakeholders only engage at Sprint Review, they’re seeing the product too late. The fix isn’t more documentation, it’s earlier collaboration and an accountable Product Owner who owns decisions.
More thoughts. Before work starts on a PBI, be clear on:
- What problem are we solving?
- How does this PBI relate to the product Goal?
- How will the PBI align with the Sprint Goal?
- How will we know it works?
The Developers should be creating the Sprint Backlog as they are accountable for that, not the PO. If the PBI is unclear, the item is not ready for Sprint Planning, and the Developers should ask for more clarity.
Thanks a lot Ian Mitchell and Chris Belknap for your responses! Much appreciate the thoughtfulness provided in your answers!
<< If it was actually possible to do any of these things successfully, then you wouldn't need Scrum. If it was possible to defer updating requirements quarterly, for example, then a Sprint would serve no useful purpose. If it was possible to somehow "sign off" on requirements, then no Product Backlog would be needed to hold an emergent body of work >>
Completely agree with your point Ian Mitchell. However, Team needs serenity of their mind and need focus to work on a set of problems that have been given by business to solve. That's why we have got the 2-weeks timeboxing of Sprints. If they work as per the current specifications mentioned in the Story and post review they got to know that this was not exactly what the Business had expected, they feel their efforts have gone in vain. They start to doubt the genuine-ness of every Story and start questioning that what are the chances that we'll not be asked to re-do the work after we showed it to the Business, that too, not because we didn't understood the requirement correctly, its because the Business changed their mind.
Chris Belknap: << The issue isn’t missing documentation - asking the business to "hand off" BRDs and PRDs is the wrong move IMHO. What us stopping you from bringing the people doing the work (i.e. the Developers on the team) into refinement sessions with the stakeholders? >>
The team didn't ask for BRDs/ PRDs at the first instance. However, because of the constant 'change of minds' happening with respect to what needs to be delivered, they started thinking of ways to address this - including documentation & sign offs. In our team, we do not prevent our members to directly work with the business stakeholders, but there is a time zone difference - team in India and business in US. So, most of the discussions are handled by PO (near-shore to Business).
Chris Belknap: << Another issue seems to be that the Product Owner is acting as a proxy and Product Backlog refinement isn’t creating shared understanding early enough, so learning happens too late and shows up as rework.>>
Product Backlog refinement happens with the Team and the PO, not with Business. The PO does a decent enough job to help the team refine the Stories properly, on the lines of the original specifications. However, if the business themselves change their mind later, no amount of backlog refinement is going to address that
A quick thought. I definately understand the team’s frustration, but this maybe more about setting expectations.
What you describe is actually Scrum at work. The business team does not fully know the requirements upfront, and their understanding evolves as they see the product. This is not uncommon and is where Scrum actually works well.
Try improving how requirements are clarified earlier is potentially one aspect, but I would also adjust expectations. Treat early iterations as opportunities to collaborate with stakeholders (business team) through examples and prototyping, rather than trying to deliver a final product. Use any feedback to refine the requirements and move toward a more complete solution only when everybody agrees.
You mentioned the business team uses language such as “demand to be fixed in the same user story.” You may need to set expectations with the business team also, so they understand the iterative nature of the process.
I assume the team may prefer to close the current user story and create a new one when requirements evolve, as this will give a sense of progress. Documentation needs and backlog tool capabilities might dictate, but it is worth discussing.