As long as Agile or Scrum was implemented on some isolated project and there was no need for an enterprise-wide implementation of Agile or Scrum across many teams, everything was acceptable. But now that the subject of enterprise-wide implementation of Agile or Scrum has become of interest, it is clear that the fact that the story point is not comparable between the different teams risks having a negative impact on a successful enterprise-wide implementation of Agile or Scrum.

To be clear, what we are referring to here is not some unhealthy or unnecessary comparison or competition among teams. What we’re simply saying is that when Scrum is deployed across different teams, the least we should expect is to be able to update management when there is a change in a project team composition, as a result of some transfer of personnel, and whether that change will affect the project deadline or not.

Unless you work in a company where you are the only member of the staff, how can you give an estimate to complete (ETC) to business or IT management when members resign from the company or transfer out of a project, if nothing is comparable between different teams?

As a consequence, you can see why it has become a problem for some PMO to plan on an enterprise-wide deployment of Scrum or Agile when the story point, and, therefore, the team velocity as it is based on story point, are not comparable between teams.

In addition to the above, as Agile and Scrum spread beyond the border of the United States into other countries, we have observed that planning poker does not always work well in non-Western cultures, especially Asian, where we come from. The reason is in many non-Western cultures, the respect for older people and for people in leadership roles often inhibits team members from coming up with an estimate that is different from that of their older or higher ranking team member.

Despite these above shortcomings, we have to say that planning poker has had a very good impact on our community as a whole, especially at the early stage of Scrum or of the Agile movement. This being said, the time seems to have come for us to find another, more objective approach, especially with the need we have for Agile or Scrum enterprise-wide deployment and resource allocation.

It would not be truthful if we said that we invented the estimating approach that follows after many years in a prestigious research lab to impress you. Instead, we will simply say that the approach we present here is a combination of ideas that originated with remarkable professionals we learned from after many years of managing and performing estimation for numerous projects of all kinds. The other thing we will say is that this method has worked on real projects that have been actually deployed.

In Figure 5.1, you will see that an application is nothing more than (1) some business users trying to interact with some working code that implements (2) some business rules running against (3) a model containing some business entities, whose values are stored in the physical database (4) which it is to create, read, update, or delete.

Figure 5.1. Different aspects of an application.

So, if we all agree, this is how we are going to estimate the user story or Product Backlog Item, one type at a time (Figure 5.2).

Figure 5.2. Interaction type.

The table in Figure 5.2 means that if the story you are looking at requires a human interaction, you should give it a value of 3. If it requires, however, only an interaction with another application, according to a well defined protocol, then that user story should get a value of 1 for the interaction.

Next, let’s calculate the complexity based on the number of business rules to be applied (Figure 5.3).

Figure 5.3. Business rules complexity.

If there is only one business rule, then you should give the story a value of 1. If there is more than one rule but less than three, then that story should get a value of 2. If there are more than three rules, give the story a value of 3.

Although the table in Figure 5.3 on the interaction type is rather obvious, we can already hear your question about what is a business rule. A business rule is a statement that tells you when you may or may not do something.

What then is the difference between a business rule and a business requirement? To simplify, a business requirement is what you need to do to enable the implementation of and compliance with a business rule as dictated by the law or by a company’s policy.

Example of a business rule:

A patron should be 18 years or older.

A possible business requirement to enforce this rule:

The patron must be in possession of a valid driver’s license or a valid US passport with photo to verify that he is at least 18 years old.

Next, we need to determine the number of data entities needed to execute this user story (Figure 5.4).

Figure 5.4. Number of business entities manipulated.

The number of entities manipulated means that if the number of data entities is only one, then you should give that story a value of 1, but if it is between two and three, then that story should get a value of 2, and so on.

Following is an example of what we mean by business entities. In this small data model (see Figure 5.5), we can see that there are three data entities total, which are 1) the customer, 2) the loan, and 3) the customer representative serving that customer.

Figure 5.5. A simple data structure with three business entities.

Finally, we need to determine the data manipulation (CRUD) factor.

Create, Read, Update, Delete (CRUD), is illustrated in Figure 5.6:

Figure 5.6. CRUD.

Let’s now imagine that one of the user stories is called “add a (conference) room.” Let’s try together to calculate its Unadjusted Points (UP) before we take into account the project’s environment dimensions (ED):

   A.   Interaction Type = 3 points
   B.   Business rules = 1 point
   C.   Number of entities manipulated = 1 point
   D.   Create, Read, Update, Delete (CRUD) = 2 points

UP = 7 points (for the Unadjusted Points for the “add a room” story or PBI).

Next, let’s take into account the Environment Dimensions (ED), which can have either a negative or positive impact on the team in its effort to deliver the “add a room” story:

For each of these dimensions, a higher value indicates higher team ability or capability, whereas a lower or minus value indicates a lower team ability or capability. A zero will mean the lowest score, while a positive value indicates a high level of ability or capability with 2 being the maximum. As you did with the previous tables, you should go through these dimensions, one by one, and see what value you should give to a question.

Toward the end of these tables (Figures 5.7–5.12), you will total the estimate in points for the story for all the environment dimensions (ED). It will vary between 0 for the minimum and 36 for the maximum.

Figure 5.7. Organization dimension.

Figure 5.8. Development infrastructure dimension.

Figure 5.9. Team dimension.

Figure 5.10. Technology dimension.

Figure 5.11. Process dimension.

Figure 5.12. Business dimension.

Depending on this total value, three scenarios will be possible:

So, to calculate the total value in points for a single story, simply use the following formula:

AP (Adjusted Points) = UP (Unadjusted Points) × C (Coefficient) PPS (Points per Story) = (AP × ED)/36

Example

Let’s take the “add a room” feature again and assume that the values of its environment dimensions (ED) are equal to the following coefficient for every dimension listed below:

   1.   Organization     =  3
   2.   Infrastructure   =  2
   3.   Team             =  4
   4.   Technology       =  3
   5.   Process          =  2
   6.   Business         =  4

Adding up all of these values gives us an ED that is equal to 18. Since ED is equal to 18, this would mean, as previously mentioned, that the coefficient of multiplication to be used will be equal to 1.

In other words, the calculation for the story “add a room” will be equal to:

AP = UP × C

AP = 7 × 1 = 7

(with UP equal to 7 points, as was calculated previously).

Then,

PPS = (AP × ED)/36

PPS = (7 × 18)/36 = 126/36 = 3.5 points.

Using the same formula for every other story or PBI, the table in Figure 5.13 provides the overall estimate for the entire product to be built.

Figure 5.13. Overall estimation matrix.

By now, it should be obvious that the advantage of this type of calculation is that it is based on objective criteria; therefore, it is more appropriate for comparison between different teams and even between different members of the same project team.

For what we have just gone through, it looks like we will be able to improve the common story card examples to make them look like that shown in Figure 5.14, and this, in order to fully take advantage of the estimation process just presented.

Figure 5.14. Improved story card.

As a consequence of Scrum success, more and more companies are contemplating rolling out Scrum to their entire IT department.

One of the impediments to this is the fact that the story point value is unfortunately not comparable between teams. With the weight of the velocity so different from one team to another, you can see why it has become a problem for many Agile PMOs to plan an enterprise-wide deployment of Scrum.

In this chapter, we offered a new technique based on an objective criteria-based estimating process in the form of a series of relatively straightforward tables to guide the team in their effort to estimate the different stories or PBIs. As simple as it is, this method allows us to make objective comparisons among teams as well as among different members of the same Scrum team.