projectdoc Toolbox

Assumptions document what you think about your product, customers, and partners. Once you start identifying assumptions, it will become clearer what other beliefs you hold about how you plan to build, design, distribute, and create value with your product. Making assumptions explicit allows to publish them and discuss them with other stakeholders.



The document type assumption provides the following properties:


Please note that only information about specific properties is provided here. Common document property used by all document types are documented by Document Properties.


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.

Risk Severity

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.

Risk Probability

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.

Domain Knowledge Ignorance

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.

Subordinate Assumptions

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


These are internal notes that are usually not exported and only visible to team members with write access.

But this is not a safe place to store sensible information. It is just a convenience for the reader to not be bothered with notes stored here for the authors for later use. The security level is about suppressing the representation by a CSS style. Therefore consider this as a convenience for the reader, not as a security tool.


The text of notes sections is also indexed.


For a document the references section contains pointers to resources that prove the statements of the document.

Often these proofs are not easily distinguishable from further information. In this case you may want to skip the reference section in favour for the resource list.


For further information please refer to References and Resources.


The resources section provides references to further information to the topic of the document.

This may be information on the internet provided by the resource or information in the team's information systems. Anything the reader of the resource might want to know, may be listed here.


For further information please refer to References and Resources.