KJ Analysis

“Affinity on steroids.”

Outcomes:

Shared understanding

Relationships

Priorities

Process steps:

1. Define the question to be asked of the data.

2. Reduce the data set to 30 or fewer items through multiple rounds of simple voting.

3. Group related items.

4. Title the groups.

5. Group related groups.

6. Create headlines for the higher level groups.

7. Visually lay out the groups with all data items.

8. Show relationships between groups.

9. Vote for the most important title‐level groups.

10. Draw a conclusion from the diagram.

We don’t have a clear definition of

what a requirement is

No clear definition of what

the difference levels of

requirements are

There seems to be

a discrepancy on

how detailed the

rqmts need to be.

I can’t delineate

between BR’s and

MR’s.

It’s not clear

where a market

requirement stops

and an SR starts

I don’t understand what the customer

needs; we don’t understand what is

important to deliver

I like to be involved in the whole process

All roles should be

involved throughout the

entire process

VOCs are very valuable

Is seems like we are

spending a lot of time putting

the same data in multiple

places and coordinating to

ensure the data is in sync

The process shouldn’t impede the

progress of the project

We’re going to

need to do some

clarification of what is

design and what is a

requirements

We don’t have a

good definition of

what a

requirement is

It seems like different

RAs have a different view

of what a requirement

should be

With requirements at

a high level it is difficult

to come up with a

good estimate

Perhaps we should

have two different

levels of use cases

We don’t know what “good

enough” is

How do you define

success at the end

of each iteration

We have lost the

concept of critical

release

requirements

We aren’t validating what

we are building with the

customer

Need to get out of the

lab exercise of I know

what the answer is now

I need to go find a

customer to tell me they

have that problem

Need to know when

we come out the other

end, have we built the

feature that is necessary

for the customer.

You better think about

performance

requirements before you

start down the design

path

Need a better way

to bring customer

feedback in earlier in

the process

VOCs are very

valuable for

providing focus to

product issues

VOCS were very

valuable which gave

us a very good

process and means

to rank and prioritize

requirements

Get engineering and

test involved earlier on

before the rqmts are

finalized

The requirement

analyst needs to

own the rqmts all the

way through the

process.

It’s difficult to look at

requirements in

ReqPro so everyone

gives up

I like the ability to

add attributes (Req

Pro)

Requirements tools are

difficult to work with

A lot of things you test

for will not show up in

requirements for

instance failure modes

If you read only the

SRs it is difficult to

understand what the

hell it is supposed to

do.

Hundreds of hours have been spend on

requirements with very specific detail for

consistency. The gap we have is that how

are we going to do a consistent design

without that level of detail

If the requirements don’t

have the detail I need,

where do I get them?

When we took UI detail

out of the use case it

wasn’t clear what the

rqmt really meant

Where do we put this

extra UI information

It’s nice to have implementation details

as an example to understand what the

RA was thinking

UI Information is a good

way to communicate ideas

Anything so that people

aren’t waiting for other

people to get stuff done

We should not have

to have everything

written down and

signed off to hand it

over the wall

No good way ot

fimplementing and

managing features access

products

We need to find a

better way to illustrate

requirements on a

features basis

All requirements

need to be

coordinated across

products

The process shouldn’t

impede the progress of

the project

To be honest, it’s to

painful to do a change

I don’t know where to go to get the information I need

Theme: Gaining a better understanding of the

requirement processes and how customers should be

involved

Lessons Learned: Better defections is needed for the

levels of requirements and where to get requirement

details,

Anatomy of a KJ Diagram

Headline

Relationshipcause and effect or contradiction

Title

Raw statement

Title with most votesTitle with second most votes Title with third most votes

Question to ask?

Summary answer.

Time/datePlaceParticipants