Product Backlog Template: Deep dive on reasoning and regulations (2..11)

<< Previous section - Back to beginning

DESCRIPTION (continued...)

Current state:

Identify the current state, no holds barred. Especially in the case of a legacy system, acquisition, or newly formed/immature team, there is likely little existing documentation. Additionally, there is a high probability that there are multiple perspectives and/or assumptions about current functionality. This is the opportunity to document, inform, and remediate those issues. –Depending upon the level of this backlog item in the overall hierarchy, this should be completed with a different amount of technical information, i.e. not specific or limited to obvious functionality.

Reasoning: Current state is something that must be identified for both requirements gathering and change management. Further, especially in the situation where one will be scaling, maintaining a legacy system, onboarding new hires, etc., there is limited understanding or documentation of the current state. For full understanding, it is important to have captured that information and in modifying it, this a perfect opportunity to get everyone on the same page. It also gives specific context for testing, both new and regression.

Regulatory guidance

There are five (5) main points in including this information:

1. Change management processes and controls are a standard requirement. While this is usually addressed with the creation of a change management board, change documents, weekly meetings, multiple levels of approval(s), etc., the beginning of each draft is to describe the system in its current state. There is no requirement for the additional work or constructs, only that the control is in place and that supporting evidence is available.

2. Best practices for SDLC (software/secure development life cycle) dictate that the first step is to identify the requirements. In the case of existing systems –a component of which seems to be present in all businesses today –there may be no centralized place where the original requirements were kept, if they were created at all. This gives us an opportunity to create that documentation in the course of daily work, as well as level-set everyone's understanding and assumptions.

3. Many overarching requirement sets specify that documentation of a system's features, components, functionality, etc., be documented and kept evergreen, i.e. up-to-date with each change, version, and/or release.

4. In addition to the previously numbered aspects, it is necessary for communication of changes, risk analysis, due diligence, and process to be documented and accessible to all parties in a company. The backlog is the perfect place to allow for that transparency.

5. In a company specializing in the development of software, the software itself is the asset. In the same manner that any traditional product company has the opportunity to capitalize upon the creation or purchase of the components to create the assets, the same is true of software companies. However, to do so, it is necessary to document each stage of the development process as only certain stages are capitalizable. As a broad generalization, to be eligible for capitalization, something cannot be maintenance and must be framed in such a way that it is a valuable feature being added to an offering. A portion of that evidence is created by fully identifying the current state of the system or deficits in the existing product's functionality.

NOTE: Depending upon the subject matter of this backlog item, this can also satisfy aspects of cyber security and trust.

To include this information in the normal course of planning and execution in the ensuing backlog, we can address all of these business concerns without any extra expenditures and in a lean fashion. We are able to work in an intentional fashion, while also tracking each piece of work back to a business proposition and value.

The referenced documents below are not fully inclusive. However, most industry standards map back to core business practice documentation without variation. (The links are a combination of industry standards and best practices as well as certain regulatory compliance documents.)

• 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 System in a SOC 2 ®, Report

• Illustrative Assertion and Opinion for a SOC 2 + HITRUST Report

• NIST SP 800-128 - Guide for Security-Focused Configuration Management of Information Systems

• PCI DSS v3.2.1

• What is change management?

• The Seven R's of Change Management

• Change Management

• The Four Principles of Change Management

• Requirements management

• What is Requirements Management?

• Requirements management: Planning for success

• Requirements lifecycle management

• Software requirements gathering techniques: A formula for success

• Capitalization of software development costs

• How tech companies deal with software development costs: Insights from a CPA

• Accounting for capitalized software cost

Next section - Goal state/Business use >>