September 22, 2015

Using TestTrack and The Scaled Agile Framework: Part 2

Helix ALM
In Part 1 of this series, we saw a pretty natural and easy way of documenting your Vision and processing epics through their assessment and approval stages. In this part, we look at how these records are used in the next stage of the Scaled Agile Framework® (SAFe®)—PROGRAM. The Program stage involves breaking down these epics into features and user stories, and planning how the work to refine them is to be done. The big idea in TestTrack is that there is no linking or duplicating from one repository to another, because all the records are stored in one tool—making the integration from top to bottom so much easier.

Stage 2: PROGRAM

[caption id="attachment_17593" align="aligncenter" width="945"]The Program Stage of SAFe The Program Stage of SAFe (CREDIT:[/caption]

Break down Epics into Features and User Stories

At some point in the process, your epics need to be broken down into features, and the features need to be broken down into user stories. I suggest doing it in this stage, but you could argue that this should be done in the previous Portfolio stage, because otherwise, how can you really decide whether or not to approve an epic? In my view, whether to do the breakdown now or in the Portfolio stage depends on your circumstance. Follow the Agile principle of self-organizing teams and do whatever works for you. What is important is that, before you do your release planning, you need to have a set of features from your epics, because these form the backbone of your plans. According to SAFe, you should also have your initial set of user stories defined for each feature. No matter how you do it, TestTrack makes it very easy to record all your features and user stories for each epic. First, create a requirements document, then create requirement types called “Feature” and “User Story.” The paragraph structure of the document provides a simple way to break down epics into features, and features into user stories, forming relationships that TestTrack can use later on. Remember our epic EP-1 “New CRM Capabilities” from the Portfolio stage? In the example below, it is broken down into features and user stories. It’s a new document, but EP-1 is still the same record. This is where the magic of TestTrack really starts to work. [caption id="attachment_17597" align="aligncenter" width="975"]Breakdown of EP-1 Breakdown of EP-1 into features (FE) and user stories (US)[/caption]

Agile Release Train Roadmap Document

According to SAFe, your overall vision for your enterprise is delivered in a number of Agile “release trains.” Each Agile release train needs a roadmap that breaks down each train into high-level iterations called “program iterations.” The Program stage involves creating this roadmap by allocating each of the features in the backlog into program iterations. The easiest and most natural way of documenting, managing, and communicating your roadmap in TestTrack is in a roadmap document. Create a requirement type called Program Increment, and organize your features into program increments in a roadmap document for each Agile release train. In the image below, you can see how two of the features needed to deliver our Ep-1 epic are planned for Program Increment 1 within Agile Release Train 1, with the third feature planned for Program Increment 2. Note, too, how the Feature Records (FE-62, FE-63 and FE-64) appear both in this document and the breakdown document above. That’s because documents in TestTrack are just views of the records in the database. All of this is gluing your process together with a minimum of manual processes. [caption id="attachment_17599" align="aligncenter" width="975"]Roadmap for SAFe A Sample Roadmap in TestTrack[/caption]

Approve and Track Features

According to SAFe, you need to effectively sequence and prioritize features in the program backlog. Depending on your situation, you may also need approval steps for features. In the example below, features are organized by program increment in a Kanban process that includes the “Funnel,” “Under Review,” and “Analysis” steps, which are an approval process. You can use this or a simplified board specifically for features, which omits these steps. [caption id="attachment_17601" align="aligncenter" width="975"]Feature Review Process folder A Feature Review Process folder in TestTrack[/caption] As part of the planning, you allocate each feature to the chosen release train in the Feature Review Process folder. This allows you to track the feature status on a train-by-train basis. (You can also see the complete feature status, should you choose to do so.) SAFe recommends using WSJF help prioritize your features, which you can do in exactly the same way you did for epics in the Portfolio stage.

From Portfolio to Program to Team

As you can see, the Program stage has to do with planning your work by allocating features and their related user stories into program iterations. In TestTrack, the epics from the Portfolio stage easily form the input for the Program stage and, without any duplication of data, break down the epics into features and user stories. In Part 3 of this series, I’ll show you how to deliver these user stories in a series of traditional Scrum sprints, continuing the process using and adding to the user stories you have already created.