Specify the type of the assumption to organize them.

Use the assumption type to define types of assumptions.

Specify the stakeholders who defined the assumption and may provide additional information.

Define the target of the assumption. Add a link to a resource that explains the target. A target may be a product, a target customer, or just anything that is worth to make assumptions for.

Select the severity of the impact on your product in case that the assumption is wrong. The value is between 0 and 100. The more severe the impact the more effort you should take to prove or disprove this assumption.

Select your estimate on the probability that the assumption is wrong. The less probable the assumption is correct, the more effort you should take to prove or disprove this assumption.

Select your estimated level of ignorance in the domain your team has to validate this assumption. The more you know the better you can control the problems arising from this assumption to be false.

Calculated priority to test this assumption.

Specify the state of the assumption by the Assumption Resolution.

State an assumption you have about the product, the customer or a partner. It's not important that you're right at first place; it is important that you write down your assumptions. They serve as a critical reminder that you haven't yet proven or disproved them. After your team discussion, assumptions are taken for granted without a proof and marked as 'accepted', are 'rejected' or are turned into hypotheses for further investigation.

Collect evidences on your journey to prove or disprove this assumption. This will help you to determine, when this assumption cannot be deemed true without proof. Then turn this assumption into a hypothesis.

In case a complex assumption needs to be organized in a hierarchy.