Track Origin of Requirements – the Source of Truth

Urs Enzler
101 ideas for agile teams
2 min readOct 25, 2018

This post is part of 101 ideas for agile teams.

Water comes from a spring, where do your requirements originate from?

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.

--

--