In my last post, I promised tips and tricks for connecting GENESYS™ to your agile toolset. In this post, I’m going to walk through an example of how you can align parts of your systems architecture model with an agile epic and user story framework in a lightweight and simple-to-achieve manner. As I explored in my previous post, using your functional model as a basis for the agile framework, and connecting the two is a great idea if you want to connect your development efforts into your systems architecture.
Let’s use an example to illustrate how to perform this connection. Imagine your program is in a test and evaluation phase, and you have modeled your test program in GENESYS. You have laid out all your test activities, and decomposed them into detailed test steps. Now you have been asked to create your test epics and user stories for each epic. What do you do next? How do you connect the two? The good news is that since you have created your test activity model, you can now directly use it to define the epics and user stories.
The first step in this example is to partition the test model accordingly. Group the top-level test activities into higher-level test activities that coincide with the top-level functions. Let’s take a robotic vacuum cleaner model as an example. Imagine a top-level functional behavior that looks like the following:
Figure 1. High-level Functional Behavior Example
This represents a very simple top-level behavior that simply partitions the behavior into vacuum functions, base station functions, and remote-control functions. The next lower level of behavior for just the vacuum component could be depicted along the following lines:
Figure 2. Lower-Level Functional Behavior Example
In this simplistic example, the robotic vacuum has a “command and control” function, a “collect refuse” function, and a “move” function. From this behavior, you can easily derive two or three top-level test activities. For this example, we can create “Conduct Command and Control Testing,” and “Test Refuse Collection” test activities. These test activities can then become the epics in your agile planning tool. They’re at the right level, and you can easily see how they would decompose into individual test activities that would then decompose once more into detailed test steps. Each level of this decomposition will relate to a type of object in the agile planning tool. The top-level test activities would relate directly to epics covering the test program, while the next level down can be grouped together into user stories.
Figure 3. Test Activity Hierarchy
As you decompose your high-level test activities, it becomes apparent that the top-level test activity flow is directly relatable to the test themes and initiatives (or whatever terminology is being used for the highest levels); the next level of decomposition contains the epics; and the final level of decomposition is directly relatable to the user stories. This test activity hierarchy is used to create the epics and user stories named in the agile tool.
Don’t fret if you are stuck with pre-defined epics and user stories that may have been created elsewhere by others who weren’t cognizant of the systems model. So long as you can relate them to different aspects of the systems architecture model, the mapping to the system architecture will still work. Of course, you’ll more than likely find inconsistencies between those pre-defined epics and user stories, and the defined systems architecture. This can then become an opportunity to push back and try to align the model to the agile epics. The key here is to adjust your processes to match your organization’s needs and methods, while trying to align them with the systems architecture model.
Now that you have created epics and user stories that match your model or aligned them with existing epics and user stories, you have taken the first step to connecting your agile development process to your systems architecture modeling. The next step is to connect the agile tool back to GENESYS. Now for the secret (or not so secret?) sauce part—how do we create traceability between entities in GENESYS and the epics/features and user stories objects in the chosen agile toolset?
All agile toolsets provide a unique identifier for the objects in their repositories. The simplest and lightest-weight way to connect the two tools is to simply extend the GENESYS schema to add an attribute to house that unique identifier for whatever classes you want to connect, and add an attribute to your agile toolset to track the GENESYS entity name. Now, if you’re sitting back and saying, “That’s it?” at this point—you’re right! It really can be this simple to create a lightweight connection between the two toolsets.
Tying together the unique IDs from the agile toolset to the entities in GENESYS establishes traceability. The hierarchy diagram below illustrates this point. Look at the revised test activity hierarchy diagram where a new attribute was added to GENESYS to track the agile toolset’s “ID,” and an “Agile Type” attribute was added to allow you to apply the type of agile entity to your GENESYS entity. Once the node definition is updated to include these attribute changes, you can now instantly see the connection to your agile framework in any diagram in GENESYS. You can also apply filters to find linked data as well.
Figure 4. Test Hierarchy with Agile Toolset Connections
What’s so great about GENESYS is that you can use the power of the GENESYS Excel Connector to make this easy. Most agile tools support csv exports and imports, and leverage that capability to simplify the data exchange. Since epics are usually fairly stable and change infrequently, the overhead of this manual method is really not that bad. User stories are best written in the agile toolset before using their unique identifiers to connect them to their related systems architecture entities. Of course, if a more robust and automatic connection is desired, more in-depth meta-model additions and changes can be made. The GENESYS API can also be leveraged to create a more automatic and deeper level connection with your agile toolset, but that’s a topic for another time.
Imagine being able to trace from your development user story to the test activities, functions, data items, and components, or any entity in your systems architecture. You’ll be able to track the development of your system in near real time—sprint time to be exact! If you’re using agile methods to track your systems architecture development effort, then you’re even more tied into the tracking effort if you take the extra step of connecting it to your systems architecture model. If you’re being asked to plan out your agile implementation of epics and user stories, you can use your systems architecture model as the guide to creating the epics/features, and you’ll likely find that your lower-level user stories will come naturally as you plan the development work, be it for test planning, or software development.
For more information, read Fragile without a Systems Model: Agile Outside of Software.
