Waves come in multiple sizes just like transactions.

Waves come in multiple sizes just like transactions.

Each of the three types of transactions identified in the IFPUG Function Point methodology are classified into three categories: low, average and high (or small, medium and large).  The process for sizing transactions is similar to the process we used to size data functions. The size of a transaction is based on the interplay between file types referenced (FTR) and data element types (DETs).  A FTR refers to an internal logical files read or updated or an external interface file read.  The function point counter will review each transaction and count the number ILFs read or updated and the EIFs read.  The total FTRs will be used to determine the size (remember IFPUG uses the work ‘complexity’).  In our example of an HR system, we described the human resource clerk sitting in front of a computer entering the data needed to add a new employee (Employee Number, Name, Address, City, State, Zip, Work Location, and Job Code), and after entering the data the clerk hits the enter key and the data is committed to the employee ILF. Upon review it was pointed out that the Zip Code entered was checked against the Zip Code file provided by the US Post Office.  The number of FTRs for this external input transaction would be two (Employee and Zip/Postal Code).  The counting rules for FTRs are no different whether the transaction is an EI, EO or EQ, with the exception that an EQ can never update a logical file. Therefore the FTRs should only reflect files that are read for EQs.

DETs are defined as unique, user-recognizable, non-repeated attributes.  This is the same definition of a DET that we used when discussing sizing data functions.  Counting data DETs for transactions is similar to counting DETs for data transactions with a few more transaction-related rules.  The rules:

Count “one” for each DET that enters or exits the boundary during the processing of the transaction.

Count “one” DET per transaction for the ability to send a response message (only one per transaction)

Count “one” DET per transaction for the ability to make the transaction happen (only one per transaction)

Using our example of entering an employee, the clerk types in 8 fields therefore the counter would count 8 DETs entering the boundary of the application.  When he or she is finished typing they will click on the post icon (or press enter) when the Zip Code is validated.  A message is returned if the Zip Code is wrong or if it is correct, and if the employee does not already exist a message is displayed saying that the employee is added.  In this case we would count a DET for the message and a DET for the ability to make the transaction happen. In our example the total number of DETs would be 10.

Just like the data transactions, IFPUG provides a simple matrix to derive size of external inputs.

FTRs 1 – 4 DETs 5 – 15 DETs 16 + DETs
0 – 1 Low Low Average
2 Low Average High
3+ Average High High

Using the matrix is a matter of counting the number of FTRs a transactions uses, finding the corresponding row and then finding the corresponding column for the number of DETs that you counted for the transactions.  In the example two FTRs and 10 DETs equates to an average external input.

The size/complexity matrix for external outputs and external inquires is a little different.

FTRs 1 – 5 DETs 6 – 19 DETs 20 + DETs
0 – 1 Low Low Average
2 – 3 Low Average High
4+ Average High High

A quick example of an external inquiry using our HR example would be if our mythical HR clerk needed to look up an employee (with same 8 fields noted before).  To accomplish this, the clerk types in an employee number and then presses enter. If the employee number is bad (or an employee does not exist) a message is returned.  If found all eight fields are displayed.  We would count 10 DETS.  We count one DET for employee number entering, one DET for pressing Enter one DET for the ability for a message and then seven DETs for all of the employee data returned (exits) except that employee number both enters and exits therefore is only counted once.   The Zip Code would not be validated on the external inquiry therefore the transaction would have one FTR and 10 DETs therefore would be a low external inquiry.

The process is repeated for each transaction.

Transaction Analysis

Transaction Analysis

Transactional analysis, originally developed by Dr. Berne, defined the transaction as the basic unit of social intercourse. When two people communicate, one person initiates the transaction. The person to whom the transaction is directed responds. Basic transactional analysis involves identifying the ego state that initiated the transaction and which ego state responded.  There are three types of transactions: complementary, crossed and ulterior, all of which you will encounter on a daily basis.

The crux of transactional analysis is the rule that effective and successful communications must be generated from complementary transactions. Complementary transactions complete a transit from the receiving ego state back to the sending ego state. If the transaction is from adult to child, the response must be child to adult.  For example, seeing that Paul the programmer is agitated during a team discussion, Sari the scrum master pulls Paul aside and says . . .”Paul you seem to be upset, tell me what you’re feeling.” The transaction goes from the scrum master’s nurturing parent to Paul’s child. If Paul responds, “I was feeling cut out of the conversation and I need help,” he would be responding from his child state to Sari’s parent.

Crossed transactions occur when the communication transaction does not return directly to the state it came from.  In the saga of Paul and Sari, if Paul had responded from his adult state to Sari’s adult state the communication would be confused and ineffective. For example, Paul asked Sari for a definition of the term upset. A crossed transaction occurs when an unexpected response is made to the stimulus. Crossed transactions occur for many reasons ranging from misinterpretations (the receiver does not understand the transaction) to misdirection (the receiver want to avoid the conversation). Crossed transactions can escalate into anger unless one (or both) parties disengage or redirects the conversation back to complementary patterns.

The third type of transaction is ulterior. Ulterior transactions always involve two or more ego states in parallel.  One portion of the transaction is generally verbal and the other an unspoken psychological transaction.  For example, if a manager tells an employee, “this is a really intriguing problem, but it it might be too hard for you.” This message can be heard either by the employee’s adult (I don’t have the capability to deal with this scenario) or by the employee’s child (I will do it and show him!).  Ulterior transactions are manipulative and increase the risk of communication failure and conflict. A better approach be to avoid innuendo and to break the conversation down into a set of complementary transactions exposing the meaning of each step in the conversation.

Teams are built on effective communication.  Very little productive work can be accomplished if communication breaks down. Agile team members need an understanding of the three ego states and how the transactions between the states can either be complementary (effective), crossed (ineffective) or ulterior (manipulative). Transactional analysis provides a framework to understand whether our communication is effective and how to get it back on track when it’s not.