Originally written by Pat Trigonoplos at the LeadingAgile blog.
Agile Chronicles – Composite Stories
Agile Artifacts – Ephemeral v. Enduring Value
During retrospection, when evaluating the quality and value of our artifacts for Epic, Feature and Story decomposition a common theme for our scrum teams is that these artifacts are by design barely sufficient and as such are ephemeral and provide no enduring value.
The design is in the code, the documentation is in the code, so we leave these artifacts attached to the engineering cards in our Agile Lifecycle Management (ALM) tool, close the cards when complete and never reference them again. Well, maybe we retain some Quality Assurance scripts that are still performed manually, but soon we will complete our QA Automation program and then the documentation will be in the code (automated scripts) and we won’t need to maintain a document artifact for QA scripts either. We accept this as a natural consequence of “barely sufficient” and we move on to the next sprint.
What if there was some undetected value in some of this information, and if sustained over time with minimal effort could provide enduring value, and help us achieve our team and business objectives.
Consider the case for managing software assets by creating and sustaining a definitive list of features for the software asset. This list becomes the feature dictionary, a common language for all teams and manifests itself throughout the Epic, Feature, Story life cycle.
Here is the brief story of an Agile Transformation and the value we discovered by performing software asset feature management and using that common feature definition to enable traceability for scrum team accountability, Quality Assurance test planning, code file ownership, portfolio analysis, competitive analysis and financial analysis.
We have just over 5M lines of code and the list of features began as a two-tiered description of 20 Capabilities and 70 related Features. The features were later delineated to 675 sub-features (about 10 sub-features per feature) to add more granularity to our traceability.
The driving business reasons for agile transformation were Quality first and foremost, but Predictability was also a problem that needed to be solved.
“We’ve done the PxQ analysis and if we dedicate two resources from each scrum team we can fix 700 defects in 9 months. We can do it in 6 months if we hire some contract resources”
Scrum teams were delineated by the list of features and corresponding software that they “own” and are accountable for. This enabled the scrum teams to focus on improving their knowledge of their software asset and focus on improving the quality of the software asset by allocating sprint time for refactoring and for reducing the technical debt that they inherited. Each defect was re-triaged in order to assign it to a specific scrum team for resolution, and as a result each scrum team had clear visibility to their defect backlog.
“You are fixing a few problems always breaking something else”.
Our client’s experience with our product was expressed as a negative impact to our business in the form of a declining Net Promoter Score and other reference-ability measurements. Participation in our client beta test program had dwindled to just a few long-term clients. The client pain manifested itself in the form of client incidents, some (or many depending on who you talked to) of which were caused by software defects. To reduce mean time to repair (MTTR), the scrum teams began providing recurring support in the form of team member rotations to the client incident triage process. They focused on resolving the incidents that were easily correctable without software changes quickly and were also responsible for assigning any defects that evolved to the scrum team that was accountable for the root cause feature set.
The predictability of delivering value to our customers depends on a well groomed backlog, how well we define the Epic that enables that value. The Epic is defined by the common list of features that are changed or added as a result of the Epic objective. This list of features per Epic is used to assign the features the accountable scrum teams, to elaborate the Feature modifications required for the Epic, define dependencies, perform Feature to Story decomposition and story point estimation.
“Why are we focusing our QA Automation efforts on an industry standard code coverage objective instead of focusing on defect hot spots and areas of code complexity? We need depth of coverage in targeted areas more than when need breadth of coverage for feature sets and features with minimal technical debt.”
Now let’s extend featuretraceability to Quality Assurance (QA) scripts and to code files in the Software Version Management tool by denoting the QA scripts and code files associated with each feature. This enables the QA team members to plan based on the complexity of the feature changes to specific code files and to schedule the automated and manual testing that is necessary during each sprint. They can further verify this plan by relating the code file change reports produced in each of the build processes during the sprint to the corresponding features and Quality Assurance scripts. This enables the focus of QA feature testing to be (not limited to, but) focused on the specific and adjacent feature sets deltas in each code build.
“Why are we using our least experienced scrum team members and contract resources to fix defects in our highest complexity code?”
Next let’s study our software asset by analyzing the cyclomatic complexity of the code files. This standard McCabe evaluation provides some insight into which code files required subject matter expertise and extra scrutiny when the corresponding features were scheduled for delta in sprint planning. These dependencies were discussed during sprint planning, annotated in the ALM tool and scheduled for early resolution in the sprint.
“Why are we doing this, why are we adding or changing this feature of the product”?
Next, the scrum teams were encouraged to ask the product managers and product owners to explain the product vision so they could include that information in their respective sprint goals and release goals. The most important question to answer for the scrum teams was “why are we doing this, why are we adding or changing this feature of the product”? The answers were usually a rote response of “competitive response or competitive advantage”.
These recurring questions led the product management team to take a more proactive approach to answering this question and use the software asset feature list for quantitative and qualitative evaluation of competing and adjacent products. Our scrum team members were able to compare the specific feature sets for which they were accountable to the corresponding feature sets of competitive products. This was a knowledge accelerator for the scrum teams and most team members made it a priority to regularly assess these competitors for feature changes and shared this information during story grooming and sprint planning sessions.