© Tasktop 2016© Tasktop 2016

Requirements Management and SAFe: Oxymoron or Practical Reality?

June 15, 2016

© Tasktop 2016

© Tasktop 2016

Feature

Epic

Capability

Initiative

Portfolio Backlog

Program Backlog

Iteration Backlog

SAFe Terms

© Tasktop 2016

Have you ever seen any of those terms in an Agile tool?

Yes!

© Tasktop 2016

Have you ever seen any of those terms in a Requirements Mgmt tool?

No!

© Tasktop 2016

Bingo. So what do you do?

© Tasktop 2016

Why is this the case?

Why should I care?

How do I overcome this fundamental disconnect?

Well, that’s what today’s webinar is all about ….

© Tasktop 2016

But wait … Aren’t we talking about SAFe …. As in ”Scaled Agile” … Why are you bringing up Requirements Management?

Requirements Management / Agile = Oxymoron?

© Tasktop 2016

Scaled = Big

Big (often =) Regulated / mission critical

I’d love to watch you describe to an auditor that the user story that was implemented for

the automatic break system for the car is just gone now because that sprint is over ;)

I’d love to watch the team recreate all the user stories necessary to implement

accessibility every time a new application for a pharmaceuticals company is being built.

I’d love to watch all of your systems engineers when you tell them “just

use JIRA stories for the specs for the propulsion engine”

© Tasktop 2016

For many organizations, your SAFe implementation will simply have to include requirements management tools.

Requirements Management

Tool

Agile Management

Tool

Test ManagementTool

© Tasktop 2016

CA Clarity

DNG

JIRA

HP QC

RTC

Tosca

Rally ServiceNowVersionOne

Blueprint

iRise

Reproduced and adapted with permission from © 2011-2016 Scaled Agile, Inc. All rights reserved.

© Tasktop 2016

So now let’s explore a bit more about why requirements management tools don’t have all the common SAFe concepts – like backlogs and sprints (remember our pop quiz at the beginning?)

So now you know why you should care … it is highly likely if you are doing SAFe, you will need *both* Agile management tools and requirements management tools.

© Tasktop 2016

Requirements Management is a much older discipline than Agile

(But don’t be deceived … that is not the most important reason)

Fundamentally requirements management is about DEFININGand agile management is primarily about DOING

© Tasktop 2016

But how then do I overcome this fundamental disconnect?

Ah. Ok. So now I know why I need to care (cuz you’ll likely need requirements management if you are “scaling”) and I also know why requirements management tools just don’t have the same concepts as Agile (DEFINING is fundamentally different and needs different concepts than DOING.)

© Tasktop 2016

It’s just like a marriage.

• You need to stay true to the basics of what each person brings into the relationship

• There will be some struggles that will take a lot of solid communicating to overcome

• It won’t be perfect

• It gets better over time

© Tasktop 2016

• Work Items: Primary goal of a work item is to hold information about work to be done

• Containers: Primary goal is to group for some purpose

© Tasktop 2016

And it is really about understanding the container’s underlying purpose that will form the basis for a successful marriage

(We have a tendency to only focus on the artifacts… which is not good – containers are equally important)

© Tasktop 2016

First, a little bit more about containers…

Scheduling Organizing Aggregating

© Tasktop 2016

Tool Type Scheduling Organizing Aggregating

JIRA Agile • Release• Backlog• Sprint

• Project

Rally Agile • Release• Backlog• Sprint

• Workspace• Project

• Portfolio Item

HP ALM Agile (ish) • Release• Iteration

• Projects• Folders

IBM DNG Requirements • Project Area• Folders• Collections• Modules

• Streams

Jama Requirements • Projects• Sets• Folders• Components

• Baselines

Blueprint Requirements • Projects• Folders

• Baselines• Reviews

Let’s See More!

© Tasktop 2016

But we already know why this is the case … remember?

Agile Mgmt Tools = DOING (Scheduling)

Requirements Mgmt Tools = DEFINING (Organizing)

© Tasktop 2016

Tool Type Organizing

JIRA Agile • Project

Rally Agile • Workspace• Project

HP ALM Agile (ish) • Projects• Folders

IBM DNG Requirements • Project Area• Folders• Collections• Modules

Jama Requirements • Projects• Sets• Folders• Components

Blueprint Requirements • Projects• Folders

Purpose

Reuse?

Compliance & Audit?

Storyboards, Diagrams?

All of the Above?

© Tasktop 2016

Compliance and Audit

I want one grouping for all requirements for my propulsion engine, another grouping for the radar system requirements. And I want both of these groupings to be contained within a higher level grouping indicating these are all “Functional Requirements” vs. “Non Functional”. I need to be able to prove traceability based on these groupings – traceability between requirements and traceability to tests and any implementations

Reusability

I want to have all of my accessibility requirements defined in one place and then “apply” them to a whole bunch of different products. These need to be able to have variants as well.

So that is step 1 … think through your core needs/purpose for using a requirements management tool

© Tasktop 2016

Tool Type Organizing

JIRA Agile • Project

Rally Agile • Workspace• Project

HP ALM Agile (ish) • Projects• Folders

Organizing Type Tool

• Project Area• Folders• Collections• Modules

Requirements IBM DNG

• Projects• Sets• Folders• Components

Requirements Jama

• Projects• Folders

Requirements Blueprint

© Tasktop 2016

Every requirement exists in one and only one folder

You can have a hierarchy of folders

Collections are essentially a “view” into requirements

One requirement can exist in multiple collections

Modules are essentially structured views

One requirement can exist in multiple modules (but it is not recommended to do that)

Let’s Talk about IBM DOORS NextGen

So let’s walk through a quick example ….

© Tasktop 2016

Our organization needs to ensure that any new web application that we build to support the business, adheres to all of the Accessibility Requirements that the federal government mandates. (Core Goal: Reuse)

Business Goal

© Tasktop 2016

Collection For App 2

Req 1 Req 2 Req 3

Collection For App 1

Req 1 Req 2 Req 3

Req 1

Req 2

Req 3

Will This Work?

Project 1

Req 1 Req 2 Req 3

Project 2

Req 1 Req 2 Req 3IBM DNG

© Tasktop 2016

Containment Sync Point

Folder

Collections

Purpose: Functional Grouping

Purpose: “Instance of” for reusability; 1 per App Project

Purpose: Execution Structure

Project Area

Purpose: Top level initiative

IBM DNG

© Tasktop 2016

Collection For Product 2

Req 1 Req 2 Req 3

Collection For Product 1

Req 1 Req 2 Req 3

Req 1

Req 2

Req 3

Problem 1: Changing Requirements

Project 1

Req 1 Req 2 Req 3

Project 2

Req 1 Req 2 Req 3IBM DNG

© Tasktop 2016

Collection For Product 2

Req 1 Req 2 Req 3

Collection For Product 1

Req 1 Req 2 Req 3

Req 1

Req 2

Req 3

Problem 1: Changing Requirements

Project 1

Req 1 Req 2 Req 3

Project 2

Req 1 Req 2 Req 3

IBM DNG

© Tasktop 2016

Collection For Product 2

Req 1 Req 2 Req 3

Collection For Product 1

Req 1 Req 2 Req 3

Req 1

Req 2

Req 3

Problem 2: Traceability

Project 1

Req 1 Req 2 Req 3

Project 2

Req 1 Req 2 Req 3

Test 1

Test 2

Test 3

Test 4

IBM DNG

Test 1

Test 2

Test 3

Test 4

© Tasktop 2016

Collection For Product 2

Req 1 Req 2 Req 3

Collection For Product 1

Req 1 Req 2 Req 3

Req 1

Req 2

Req 3

Problem 2: Traceability

Project 1

Req 1 Req 2 Req 3

Project 2

Req 1 Req 2 Req 3

IBM DNG

Test 1

Test 2

Test 3

Test 4

Test 1

Test 2

Test 3

Test 4

© Tasktop 2016

Bummer. So let’s try a different approach.

© Tasktop 2016

Module For App 2

Req 1 Req 2 Req 3

Module For App 1

Req 1 Req 2 Req 3

Req 1

Req 2

Req 3

Will This Work?

Project 1

Req 1 Req 2 Req 3

Project 2

Req 1 Req 2 Req 3IBM DNG

© Tasktop 2016

Containment Sync Point

Folder

Modules

Purpose: Functional Grouping

Purpose: “Instance of” for reusability; 1 per App Project

Purpose: Execution Structure

Project Area

Purpose: Top level initiative

IBM DNG

© Tasktop 2016

Module For Product 2

Req 1 Req 2 Req 3

Module For Product 1

Req 1 Req 2 Req 3

Req 1

Req 2

Req 3

Problem 1: Changing Requirements

Project 1

Req 1 Req 2 Req 3

Project 2

Req 1 Req 2 Req 3IBM DNG

© Tasktop 2016

Module For Product 2

Req 1 Req 2 Req 3

Module For Product 1

Req 1 Req 2 Req 3

Req 1

Req 2

Req 3

Problem 1: Changing Requirements

Project 1

Req 1 Req 2 Req 3

Project 2

Req 1 Req 2 Req 3

IBM DNG

© Tasktop 2016

Module For Product 2

Req 1 Req 2 Req 3

Module For Product 1

Req 1 Req 2 Req 3

Req 1

Req 2

Req 3

Problem 2: Traceability

Project 1

Req 1 Req 2 Req 3

Project 2

Req 1 Req 2 Req 3

Test 1

Test 2

Test 3

Test 4

IBM DNG

Test 1

Test 2

Test 3

Test 4

© Tasktop 2016

What would the equivalent look like if I was using Jama instead of DNG? (And consider if it was HPE ALM instead of JIRA)

Their containers and purposes for those containers are different

© Tasktop 2016

Tool Type Scheduling

JIRA Agile • Release• Backlog• Sprint

Rally Agile • Release• Backlog• Sprint

HP ALM Agile (ish) • Release• Iteration

IBM DNG Requirements

Jama Requirements

Blueprint Requirements

It’s not just about organizing … what about scheduling?

© Tasktop 2016

Use an organizing container to be a scheduling container

Issue 1: Maintenance

Issue 2: Dynamic movement

Issue 3: Now you’ve lost your organizing alignment

(If my collection is meant to allow for some amount of reuse then I’ve lost that ability)

Flow the sprint/release information as attributes of the actual requirement

Better choice!!!

Two Basic Choices

© Tasktop 2016

But wait … there are still more considerations .... What about baselines? And reviews?

We don’t have time to talk about those today … but know that they play a definite role in your success

© Tasktop 2016

In Summary….

You will really need to think through your flow strategy to successfully

implement SAFe in an environment that requires requirements management

You must really understand containers to be successful at this

There is not a one size fits all solution – it is tool specific and organization

specific because each tool has different containers for different purposes

(and there are very tool specific nuances that are important to understand)

© Tasktop 2016

Understand what each container type is intended to be for

Understand if an artifact can be in more than one container

If an artifact can be in more than one container, understand whether a change made to any instance of that artifact will change the rest of them

Very important to consider how relationships are handled (esp in a reuse scenario)

Represent the notion of release and sprint as attributes/fields – not as a organizing container “masking” itself as a scheduling container

Tips and Tricks

© Tasktop 2016

Often using one way flow is the best choice for requirements - the requirements system is often considered the “single source of the truth”

Recognize that the way you want to flow requirements to an agile test management tool might be different than how you will want to flow requirements to a agile development tool

Start small and experiment!

Talk to the business analysts and developers and really understand how they do their work and *why* they have structured things they way they do.

Tips and Tricks

© Tasktop 2016

We Want to Hear From You!

• Survey will be sent out all about containment!• Any other questions: http://go.tasktop.com/contact-us

© Tasktop 2016© Tasktop 2016

tasktop.com@tasktop