What does the Risk field mean in a User Story?

Question

My team is using VSTS with the Agile process. When creating a User Story, there is a Risk field with options High, Medium and Low. We've searched through both the Agile and Scrum processes VSTS documentation to get an explanation as to what risk this represent, but found nothing.

We tried to reach consensus as to what "risk" the field is referring to but ended up undecided between these three definitions:

• Risk (as in chance) of the actual outcome (the resulting feature/implementation) not being the desired outcome (in the sense of the actual outcome not being approved by stakeholders)
• Risk (as in chance) of impediments/issues appearing that blocks development (such as having to research and buy a new tool/framework (such as a zip-code database) in order to implement the user story)
• Risk (as in "severity of the consequence") of getting the implementation wrong (such as having a bug in a operation that may involve a lot of money)

What does the field mean? Does this affect in any way other metrics in VSTS (such as Stack Rank)?

Answer 1

If truly working within the agile philosophy, as there is no Agile^tm process, then look at the first value: Individuals and interactions over processes and tools. The tools are there for the people. How does this field, and others, best make sense for your context?

The original intent of a user story was for recording the general idea. As its use has grown over the years, so has its information bloat. It is important for a product team to understand the intended value and potential risk, so many tools have added fields for these values. Much like the Severity and Priority fields for bugs, one's specific context should drive their meanings.

Most of these fields are independent: Microsoft Docs 1 2

A subjective rating of the relative uncertainty around the successful completion of a user story.

Defined allowed values are:

1 - High

2 - Medium

3 - Low

Answer 2

Risk field for a User Story is not relevant

I have not used VSTS. However, I have used TFS, which is a close in-premise version of the Microsoft cloud service VSTS. At least I would think they are pretty close for the Agile process.

At the User Story level, I think it refers to your second bullet:

Risk (as in chance) of impediments/issues appearing that blocks development...

I think you should focus on reducing the risk in User Stories, rather than putting a lot of effort in tracking it as a property of the User Story.

1. In the Backlog Refinement meeting, focus on getting clarifications from the PO/stakeholders, adding more detail, adding acceptance criteria and estimates.

2. If you still feel there is risk, take up a time-boxed research story, also known as a spike. In this research story, a team member can build a proof-of-concept, which helps to minimize the risk and firm up the estimate.

Also, it is the designated responsibility of the Scrum Master to remove impediments in the way of the Development Team accomplishing the stories in the Sprint Backlog.