DESCRIPTION (continued...)
Goal state/Business use:
Identify the desired state, to whatever level of detail is necessary at the appropriate level. This is also variable based upon the level in the overall hierarchy –and why the ability of your tool to support those hierarchy-level minimums is crucial. At the epic/roadmap/initiative level, this should provide not only the desired capability and the metrics associated to the market value or quantification of ROI. –Notice that I used the word "capability" and not "functionality." This is part of the "why," not the "how." The "how" will be informed at the "feature" level or below. The highest level CAN contain the "how" information or expected steps, but it is not a requirement here. In most cases, that information would only be completed for added context in portfolio level planning to aid business stakeholders in understanding the complexity of an initiative that may not be immediately evident. By the time that the engineering or working team is reviewing and decomposing these items, they should be able to accurately describe TOGETHER what will be done, at a technical level. This needs to be documented as well so that anyone on the team is able to take ownership and execute on the tasks during an iteration in the appropriate priority order and break-down any existing knowledge siloes.
Reasoning: Business use/goal state is something that must be identified for both requirements gathering and change management. This also helps to provide scope for the work and helps to tie everyone to the “why.” One of the biggest developer complaints is that they are disconnected from the company and/or the overall reason for why the work is being undertaken. Identifying both the current state and goal state with the business use provides the side benefit of allowing for feature sets to be grouped together as maintenance or enhancement and thus allowing for software capitalization.
Regulatory guidance: By providing this information, we have successfully documented this aspect of the system as it currently stands and the first requirement for addressing change management –without the need for other working groups and support of specific change management documents and workflows. This also satisfies the guidance (and sometimes regulatory requirement) for knowledge access and sharing across the company. Depending upon the subject matter of this backlog item, this can also satisfy aspects of cyber security and trust. (The referenced documents are not fully inclusive. However, most industry standards map back to core business practice documentation without variation.)
TSP Section 100 - 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (updated March 2020)
DC Section 200 - Description Criteria for a Description of a Service Organization's System in a SOC 2 ®, Report
NIST SP 800-128 - Guide for Security-Focused Configuration Management of Information Systems
PCI DSS v3.2.1
Comments