Archives for March 2019

The above is an overview of the semi-classical estimating process. The process is fueled by the initial user stories. Conceptually, the result is a burn down chart that will show how many iterations will be required for the next release. The required team size is also predicted.

At this high level, it looks like semi-classical estimating does the same thing that modern agile estimating techniques. However, it does it in a completely different way. It can be used in situations where agile techniques alone are not possible. For example, the modern agile estimating approach relies heavily on estimates provided by the development team. However, there are times when an estimate is necessary before the technical team has been assembled. Without a technical team, the use of techniques like planning poker are not possible. However, the semi-classical approach outlined here can still be used. An independent estimator or a product owner can develop the estimates using semi-classical estimating.

Even when the technical team is available and an estimate has been made using the typical agile approach, this semi-classical estimating can give an orthogonal estimate. It is independent of the one that is done by the agile team. Often, estimates done by the development team can be flawed. Before agile development, estimates were often done by project managers. They were trained in estimation and were often good at it. They were also trained negotiators and were often good at that to. They often turned their estimates into negotiations for more resources. They could not lose. If they took longer than they thought they would, they had already negotiated a contingency. If they finished early, they appeared to be heroes by bringing in the project under budget. This mentality can rear its head with development teams today.

The reverse phenomena can also occur. Several years ago a project team was scheduled to go into user acceptance test in another week. The executive management of the software development firm was uneasy about the situation. I was sent to see what was happening. I interviewed a variety of developers. I spoke to one in particular that I had known over the years. He was smart and I was sure he would tell me the truth. I asked him about the functionality that his group was developing. He was having trouble explaining it. He then said, “it is too bad you cannot stay until next week. We are going into user acceptance testing and I could show it to you.” He was not stupid and he was not lying. He was the victim of groupthink. I knew that the project was about a year away from completion. The client canceled the job after a few more months.

An independent estimator or a product owner with training in semi-classical estimating would be able to generate an estimate. Either of these people could estimate independently from the agile team. They should be immune to the biases described above. Their estimate and the agile team’s estimate could be compared in an effort to get to the best estimate.

The picture above is of the Large Hadron Collider. It was built by the European Organization for Nuclear Reserarch, also known as CERN. It is a 17 mile circle of magnets that are designed to accelerate subatomic particles, including parts of hadrons, in an effort to discover other subatomic particles and to understand the very nature of reality itself. Accelerators used to be called atom smashers because they were used to break atoms into their subatomic particles. We all studied protons, electrons and neutrons in school. However, the atom is composed of a menagerie of particles including quarks, photons, neutrinos and the Higgs boson.

In semi-classical estimating, the first thing to be done is to smash the user stories into sub stories. Agile developers are taught to INVEST (Independent, Negotiable, Valuable, Estimatable, Small and Testable) in good user stories. Semi-classical estimators know that these user stories are seldom estimatable in themselves. Even a small simple story like, “As a sales manager, I can input a salesperson profile” has at least two sub stories associated with it: an elementary process to input a salesperson profile and a logical file of salesperson information. Just like subatomic particles, our identification of sub stories is evolving. Certain types of processes, like maintenance screens, are sub stories. Many types of sub stories have already been identified. It is likely that different problem domains will eventually have their own sub stories. These will be templates that are constantly being used and eventually will be recognized as templates or patterns for estimating purposes. In the meantime, elementary processes are a type of sub story that can be used in combination to represent the other functional sub story. For example, if maintenance screens were not identified as sub stories, they could have been represented as 4 elementary processes: add, change, delete and an implied inquiry.

Function Point Analysis has been with us since the seventies. It was a technique designed to estimate software development time. At that time, software projects were usually produced in a big bang. Suppose that you had a 2,000 function point application to develop. This was large, bordering on huge. Still, lots of these projects were done. About 10% of new software development projects fell into this range. A project like this would probably be estimated to take a calendar year. Using a waterfall approach, team size would vary. About 10 people might be involved in analysis, but the team might ramp up to 30 people when the coding phase began. In any case, there was no workable system available until the year was up. Function points worked fine for this, but this is not the way software is developed today.

Using an agile development approach, this same project might be delivered in five releases. The first would be expected in a couple of months. It might have only 300 function points of the eventual functionality. However, it might be estimated in a manner very similar to the one above. However, estimating the next release is not as simple. The next release involves new functionality. It also involves changing functionality that was added in the last release. Simplified versions of some screens, interfaces and files may have been implemented in the first release because it was “the simplest thing that could possibly work.” There have been some issues with using function points to estimate these changes.

In 2007, the International Function Point Users Group (IFPUG) approved the creation of a Software Non-functional Assessment Process (SNAP). It was intended to measure the technical (non-functional) aspects of software requirements. Between it and function points, it was hoped that better estimates of software development effort could be made. This has happened, but not in the manner that some people expected. It turns out that SNAP was a good predictor of the effort involved in software modifications. In semi-classical estimating, a somewhat enriched form of SNAP is used to estimate the changes that will naturally occur as the development team moves from one application release to the next.

The estimated function points and enriched SNAP points together make up the consumer size of the application being developed. It is a driver of the effort required to produce the software, but it is incomplete. The development environment must be considered. Different development environments have different gearing factors. When data processing began, many applications were written in Basic Assembler Language (BAL). BAL programmers had to decide where in storage their data would reside. They had to move them to computer registers before they could perform operations like addition on them. Programming was a laborious process, far removed from the business problem that was being solved. After some time, the COmmon Business Oriented Language (COBOL) was developed. An expression like “ADD A to B” was all that was required to add two numbers. The programmer did not have to consider what was in the registers or where they were in memory. COBOL programmers expanded less effort to solve the same problem than BAL programmers did. Some people would say that COBOL was more highly geared than BAL. Another way to look at this was that for the same consumer sized application the one developed in COBOL had a smaller producer size.

In the eighties, Barry Boehm (no relation to Ray Boehm) published Software Engineering Economics which introduced the COnstructive COst MOdel (COCOMO). It was actually a set of models that were useful in estimating the effort and schedule for software development. They were primarily driven by source lines of code (SLOC), but with software development environments like Excel, the concept of a line of code started to lose meaning. Producer size is a more relevant way to think of this. Since that time, a COCOMO II has been released along with several other related tools in the COCOMO suite. Some are more relevant to agile development than others. In any case, the objective is to establish the team size and how many months it will take to develop the next application software release.

In 2001, 17 methodologists met in Snowbird, Utah to discuss software development practices. The result was the Agile Manifesto. It stated that “We are uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value the following:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items of the left more.”

The fourth value has been a source of misunderstandings between agile developers and classical estimators. After all, if you do not value following a plan, then why estimate at all? Some early agile developers believed this. They felt that if they were given a budget to start work, after a couple of iterations they would be able to estimate how much time was left. They were sure that traditional estimating techniques like function point analysis, software non-functional assessment process (SNAP) and COCOMO had no place in their agile world. To some extent, they were right. Companies experimented with agile development on low risk projects. If the project failed, it was a lesson learned. If it succeeded, it was a victory for agile development practices. More projects succeeded than failed. Agile development continued to move into the mainstream of software development. Agile teams were tasked with projects that were critical to their organizations. They were no longer low risk experimental projects. Now, organizations needed estimates of when software would be released.

Unfortunately, they could not just dust off the traditional techniques and use them like before. Some of these techniques required artifacts that would never be produced by an agile project. For example, function point counters were used to doing counts based on external design documents. These documents are never produced in an agile project. You could perform the count based on the completed release but by then, the development time would be known and an estimate would be of no value. Furthermore, the typical results for many of these classical techniques are of no value to the managers of agile projects. COCOMO normally produces an estimate assuming that the work will be done using a waterfall methodology with separate steps for analysis, design, coding, etc. It is not uncommon for estimates like 10 people for 10 months to be generated. First, there are not separate phases in an agile project. There is no analysis to generate some type of requirements document. Instead, functionality is generated with each release. Analysis, design, coding, etc. all occur at the same time. Also, no agile release should be planned for 10 months after the last. Releases come much more quickly.

In agile projects, the basis for all estimating and planning appears to be the user story. The user story is written by the customer. Traditionally, they were handwritten on cards. Most organizations now enter them into a document or a tool whose purpose is to capture and track story cards. User stories usually have a format like this example: “As an account owner, I can enter information for checks that are written.” It is not really a requirement statement because it does not specify what data is entered. However, to be a good story, it should be capable of being estimated.

One of the early estimating techniques, and one that is still common today, is the use of story points. If you have a set user stories, choose one that is about average in the amount of time you think would be required to implement it. Assign that a value of 8 story points. Now take each of the user stories and decide how long they will take relative to the 8 story point user story. Suppose the next user story looks like it will take twice as much time to implement as the 8 story point one. Multiplying 8 by 2 gives 16. However, story points must be 0, 1, 2, 3, 5, 8, 13, 20, 40 or 100. The closest number to 16 is 13; assign the new user story a value of 13 story points. Note that some practitioners use a value of 4 in place of both 3 and 5. User stories that do not get implemented as functionality, for example “as a user, my input screens are artistically pleasing” get 0 story points. Nothing gets over 100 story points. In fact, as it gets closer to the time when the 100 story point stories are to be implemented, they are often decomposed into a set of smaller user stories.

User stories are often assigned story points through a collaborative exercise called planning poker. Planning poker is played by the developers. Each developer has a set of cards with the values 0, 1, 2, etc. based on the numbers of possible story points. Someone reads a story. Everyone puts done the card that corresponds to the number of story points that they think should be assigned. If everyone agrees, the value is assigned. If there is disagreement, then the person who chose the smallest value and the one who chose the largest one should share their thought process with the group. Then the group selects values again. Some people may have been influenced by the thoughts of the people who explained their extreme values. This continues until everyone reaches a consensus regarding the number of story points. Then the same process is repeated with all of the user stories. It is critical that the planning poker session does not bog down in lengthy discussion over a single user story. If anyone on the team thinks that is happening, they should call a two minute warning to force people to compromise on a value by the end of the two minutes. Planning poker can be played with physical cards and the team gathered together in one place. There is a web site at planningpoker.com where there is a virtual version of the technique.

When it comes to T-shirt sizes, the agile community is in complete agreement that XS < S < M < L < XL. Some practitioners only use S, M, and L. In any case, they are similar to story points in that they are relative. They are used to compare the estimated work to implement user stories. However, with story points, the relationships are explicit. For example, it should take 4 times as long to implement an 8 story point user story than to implement a 2 story point one. There is no such generally accepted relationship between a small and a medium t-shirt size story. Some practitioners use both T-shirt sizes and story points. They use T-shirt sizes on epic stories that may be implemented over several sprints. Later, before they begin to delegate these stories to sprints, they decompose them into smaller stories which they estimate with story points.

Kent Beck introduced the eXtreme Programming methodology. This was probably the first popular agile methodology. He introduced ideal time as the estimating measure. He defined asking the question, “how long would this take without distractions and disasters?” Developers that are new to a team, technology or problem domain might spend a week to deliver 8 hours of ideal time because of learning curve considerations. Beck would say they had a loading factor of 5. Even experienced developers usually have a loading factor of 2 because they are involved in meetings and spending time coaching less experienced developers. When a 5 person agile team knows they have 100 ideal hours of work left, they know that they will have trouble finishing up in two weeks. When management hears the same thing, they expect everything to be done next week. Any gap between ideal time and calendar time can be made up with some unpaid overtime. It’s part of being a professional!

It should be emphasized that story points, t-shirt sizes and ideal time are actually generating estimates for a particular team to implement user stories. They will be irrelevant for other teams. Each team has different capabilities. Another team may take much longer or be much quicker. Of course, some teams may be poor at estimating.

The actual work of software development is done in a series of iterations. In scrum, they are called sprints. During each iteration, some number of user stories are implemented. These iterations are usually between 1 and 4 weeks. The iteration length is usually set by the organization. If a software development organization is running 6 agile projects, they will all be doing iterations of the same length. They are time boxes. They usually involve the whole team. Thus if you have a 5 person team doing a 2 week iteration, it will take 10 person weeks over a two calendar week period. This is not an estimate, it is an exact number. In agile development, the team members are urged to limit overtime. In fact, they are forbidden to work overtime 2 weeks in a row. The amount of functionality that is implemented during an iteration is estimated based on the number of story points or ideal time. T-shirt sizes are difficult to use because it is hard to mix the non-numeric sizes like small and large to come up with a velocity. If the previous iteration implemented 50 story points, then the next iteration should do the same. However, if the iteration does not achieve this, then it stops when the time box is completed. Likewise, if the work is done early, then additional user stories are worked on.

Releases are working software that the end users will use. Some of the iterations will result in a release. According to the agile principles, new releases should be generated every “couple of weeks to a couple of months.” Estimating when this will happen can sometimes be done tracking the velocity of iterations using story points or ideal time. Then the number of iterations required to implement the user stories in the release can be predicted. However, this approach has not always been sufficient. In those cases, semiclassical estimating has been necessary.