Differences

This shows you the differences between two versions of the page.

--- how_do_we_write_good_features [2020/06/04 09:17] – Removed LINKBACK hans
+++ how_do_we_write_good_features [2020/06/04 09:19] (current) – Added hypothesis notion hans
@@ Line 23: / Line 23: @@
   * Title: The title briefly conveys the intended business purpose or outcome, using business terms. The title should not specify a particular technology or solution (unless its inclusion is necessary for understanding). It should complete the sentence “I wish the system would …” and should start with a verb.  An example is:  Provide 2017 SBC Template.  Prefixes can be used if they aid in sorting and grouping of features within an epic. Use brackets [] to distinguish prefixes when used.
   * Description: This provides more detail about the business purpose of the work, within the constraints of the scope of the feature.   One format is:  The purpose of this feature is to <insert high level business requirement> so that… <business outcome or benefit>.  Additional business requirement details and benefits should follow within the description.
-  * Benefits: Describe the value expected from the business from this feature (not the entire epic). This should include both tangible and intangible outcomes. If the value is only pertinent in conjunction with other features – that should be articulated. If available: include pertinent quantitative information about number of users impacted, dollars saved, FTE savings, etc. This is the place to reference, or provide a link to, any pertinent ROI or tangible benefits from the epic business case, if applicable.
+  * Benefits hypothesis: Describe the value expected from the business from this feature (not the entire epic). This should be in the form of a hypothesis - we think we want this, but we don't necessarily know this. It should include both tangible and intangible outcomes. If the value is only pertinent in conjunction with other features – that should be articulated. If available: include pertinent quantitative information about number of users impacted, dollars saved, FTE savings, etc. This is the place to reference, or provide a link to, any pertinent ROI or tangible benefits from the epic business case, if applicable.
   * Acceptance Criteria: Describes how we know the feature is done; it describes the expected result in a way that can be verified. This field is often referenced to reflect the scope of the desired end result of the feature.  It is used by system architects and agile teams in their estimating.
   * Epic / Portfolio Item:  This field ties the feature to the associated epic which is often a way of describing the funding source (e.g. project).