Track Origin of Requirements – the Source of Truth
This post is part of 101 ideas for agile teams.
Context
Your team does not know from whom requirements are from:
- Who had the idea?
- Who has the described problem?
- Who benefits from the solution?
The team does not know who to ask for clarification if there are questions, or the team asks different persons resulting in different answers.
Different answers lead to misunderstandings or a drift in the requirements. Sometimes when the team shows what was built, the person, who had the idea, responds that this does not solve the original problem.
Action
Note the origin of the requirement on every product backlog item. If there are questions, go directly to the origin.
If the product backlog item is the result of several people — e.g. the result of a workshop — note all persons that were attending the workshop.
Be cautious when adding another origin to an existing product backlog item. Make sure that both persons have exactly the same problem and need the same solution. Otherwise, keep both versions as separate product backlog items.
In the Review with the stakeholders, show the solution to the persons noted as the origin for the done product backlog item.
What you gain
You can ask for feedback from the person(s) that were the origin of the requirements.
You have s single point of truth to ask questions to for every single product backlog item.
How to strengthen
Empower your team to talk directly with their stakeholders.
Risks
Different stakeholders want conflicting functionality. → Either find a consensus among the affected stakeholders or build dedicated applications for the conflicting functionalities.
Please help me improve this idea by providing feedback.
More ideas at 101 ideas for agile teams
Many thanks to bbv Software Services for making this blog post possible.
