I can’t resize the run even if is straight uphill both ways!

The question of resizing a story has many variations based on the rationale the asker is using. Rationales include stories:

  • that the work is harder,
  • take longer,
  • for which someone else is going to do the work, or
  • on which people missed the boat entirely.

If the answer given is no, the immediate next question is often “If not, then when does it make sense?”  Let’s start with the easy part of the answer. (more…)

Prices

Prices

In classic economics, a price represents an equilibrium between supply and demand or value and scarcity. This suggests that there should be a close relationship between the estimate and the price. However, the difference between pricing and an estimate is the pricing strategy. Over the long term in commercial organizations the price must be equivalent to estimate plus a planned margin. In the short run for any specific account the relationship can be significantly more variable and nuanced. Pricing strategies work because IT sourcing markets are not perfect markets.

The classic equilibrium theory assumes absolutely free markets without barriers. Software development, operations or other IT staffing scenarios typically have several market imperfections (this is most true in the short run), which make pricing strategies effective. For example, a price to win strategy might be to price the work using lower margin (or negative) in order to get into an account, with price escalation in the longer term to get back to a planned margin. You can see this strategy in your local grocery store where prices are marked down to entice switching or stockpiling (stockpiling is useful to resist competitive pressures).

An estimate describes what sourcer thinks will be required to deliver the work, and therefore is an absolute based on what is known (and many times what is not known). The estimate is a step to a price, but only a step. The most basic formula would be:

 Price = Estimate * Planned Margin

The margin is a function of the pricing strategy. The equation could be enhanced (or complicated) by adding timeframes. In this model the estimate, unless new information is encountered (e.g. scope change, different resource costs, inaccuracies or process improvements), is a constant. That means that if the organization wants to change the price, they will need to change the expected margin or find other efficiencies. What should not happen is that a price change results in a command to change the estimate without some substantive rational.

In internal organizations, the relationship between an estimate and what is charged (charged back or applied to budget) is typically the same with the possible exception of an allocation of overhead. There is little need for an internal pricing strategy, as internal IT organizations are typically run as cost centers rather than as a business. In later articles we can discuss both the positive and mostly negative outcomes of this behavior.

In commercial IT (application development, support and operations), the price that ends up being charged or in the contract should be related to the estimate.  Related as modified by the pricing strategy being used to capture the business. Where there are market imperfections, such as high barriers to switching, that difference between the estimate and price is tilted toward the sourcer. Estimates are an input to the price, but only that – an input.

note (1)Is a good idea for teams to work on more than one project at once?  The logic leading up to the question usually begins with a statement like, “Our team is 15% on project A, 40% percent on project B and 45% on project C.  Being fully loaded makes us more productive, right?” Before I answer I generally have to take a deep breath, otherwise I tend to build up quite a head of steam. The simple and easily provable answer is no (the Multitasking Name Game drives the point home nicely). I am sure there are special circumstances where the answer is yes, however I have never seen that circumstance in the workplace.  Multitasking, switching costs and potential bottlenecks will all conspire to make this behavior inefficient and probably ineffective.  The problem is that both individuals and teams conflate the idea of being really busy with being highly productive.

Focused, dedicated teams generally reflect the following attributes:

  • They have a common goal that provides direction.
  • They tend have fewer cross purpose conflicts resulting from deciding which project is more important at any point in time when bottlenecks occur.
  • They can plan their work more easily, which reduces project multitasking. This, in tern, will yield an increase flow of work through the team.
  • They tend to be more efficient due to less switching between tasks to support multiple projects.

Much of the benefit of single threading projects comes from the efficiency gains generated by planning and organizing the work so that team members are effectively utilized and work flows through the process without stopping. Multitasking at either an individual or team level reduces efficiency.  Focusing on one goal at time is significantly more efficient, however it does effort for planning. Here again, focusing on one project at a time reduces the overhead of planning.

How fast are you getting to where you're going?

How fast are you getting to where you’re going?

What is the difference between productivity and velocity?  Productivity is the rate of production using a set of inputs for a defined period of time.  In a typical IT organization, productivity gets simplified to the amount of output generated per unit of input. Function points per person month is a typical expression of productivity.  For an Agile team, productivity could very easily be expressed as the amount of output delivered per time box.  Average productivity would be equivalent to the team’s capacity to deliver output.  Velocity, on the other hand, is an Agile measure of how much work a team can do during a given iteration.  Velocity is typically calculated as the average story points a team can complete. Conceptually the two concepts are very similar, the most significant differences relate to how effort is accounted for and how size is defined.

The conventional calculation for IT productivity is:


productivity

Function points, use case points, story points or lines of code are typical size measures. Work in progress (incomplete units of work) and defective units generally do not count as “delivered.” Effort expended is the total effort for the time box being measured.

The typical calculation for velocity for a specific sprint is:

velocity

Note, as a general rule, both metrics are an average.  One observation of performance may or may not be representative.

The denominator represents the team’s effort for a specific sprint in both cases, however when using velocity the unit of measure is the team rather than hours or months. Average velocity of a team makes the assumption that the team’s size and composition are stable.  This tends to be a stumbling block in many organizations that have not recognized the value of stable teams.

The similarities between the two metrics can be summarized as:

  • Velocity and productivity measure the output a team delivers in a specific timeframe.
  • Both metrics can be used to reflect team capacity for stable teams.
  • Both measures only make sense when they reflect completed units of work.

The differences in the two metrics are more a reflection of the units of measure being used.  Productivity generally uses measures that allow the data to be consolidated for organizational reporting.  While velocity uses size measures, such as story points, that are team specific. A second difference is convention. Productivity is generally stated as # of units of work per unit of effort (i.e. function points per person month), while velocity is stated as an average rate (average story points per sprint).  While there are differences, they are more a representation of the units of measure being used than the ideas that the metric represents.

Add a little sparkle to your routine.

Add a little sparkle to your routine.

What does “walking the board” mean? A team that walks the board focuses discussion on one story at a time.  When walking the board during a daily meeting, team members talk specifically about that story; describing what had been done, what will be done and what was in the way. By focusing on one story at a time the team can really focus holistically on the piece of work.  Why “walk the board” instead of the standard daily meeting format? There are generally two reasons.  The first is that even the best techniques get stale without variety. The second, walking the board promotes team-level coordination.

Daily meetings, whether Scrum or stand-up, follow the same basic form. Generally each person answers three questions: what did I do, what am I going to do and what is blocking my progress. After several months of doing your daily meeting the same way, regardless of how quick and focused it is, they can get stale. Stale techniques lose their effectiveness. Team members just go through the motions without really communicating with each other.  If a Scrum Master should have at least nine techniques for retrospectives, why would only having a single technique for the daily meeting make sense?

When a team walks the board, the discussion begins with a story.  When I am facilitating a daily meeting I usually randomly select the first story and then let the team direct the flow.  I have seen others select the story at the bottom of their list or board.  Everyone currently working on the story answers the standard questions as they relate to that specific story. The difference in the process is subtle if only one person is working on that particular story, however if multiple people are actively working on the story you will see the difference.  It will shift the focus to the story and promote coordination.

Walking the board addresses the age of problem of process boredom by providing the team with a second technique for their daily meetings because daily meetings are necessary for the team to plan.  Planning only happens with communication and coordination.  Process boredom is the natural enemy of communicating.

Function points and story points are similar, but different. Like the different kinds of eggs.

Function points and story points are similar, but different. Like the different kinds of eggs.

What is the difference between story points and function points? Both function and story points are a measure of size, but they are derived by different means. The big difference is that story points are a measure of size determined by the team, while function points are a measure of size based on a standard set of rules[1].  There is not a perfect analogy, but one that I use is that the difference is like measuring the distance between New York and Chicago in miles or the number of rests stops I’d need if I was driving. Both are predictable, however only one is understandable outside of my team.

Function points (see What is a function point?) are a measure of the functionality delivered by the project or application.  All of the different types of function points are based on a set of rules that can be applied consistently by any trained practitioner.  Size is generally reflective of a count of a set of components (External Inputs, External Outputs, External Inquires, Internal Logical Files and External Interface Files).  The size of each component is judged based on attributes like fields, files and groups of data.

Story points are based on the team’s perception of the size of the work.  The determination of size is based on level of understanding, how complex and how much work is required compared to other units of work.  For example, one team might feel that developing a new service to insert customer records in a database is complex and large, while another team might perceive the same piece of work as less difficult. Scales for story points vary, however the two most common are the Fibonacci sequence and Cohn’s numbers.

Both function points and story points can be used to gauge how much work can be accomplished in an iteration or release.  The difference between the two sizes is generally who is involved in making that determination: the project team or an estimator. Another difference between the two measures of size can be seen in the how story points and function points can be used in organizational measurement programs.  Simply put, since story points are a reflection of the perception of a specific team they can’t be used to compare performances across teams, nor can they but summed up to generate organizational metrics.

Story point and function points represent size.  Story points are created by a specific team based on the team’s cumulative knowledge and biases.  The result of developing story points is useful to help the team plan, but not useful outside of the team.  Function points are a reflection of size based on a standard set of rules, rules not developed by the team therefore less intuitively understandable, but more useful at an organizational level.  If the question then becomes, “Which measure of size should I use?” The answer, as always, is it depends on what you need the information for.  If you are collecting organizational metrics, using parametric estimation or have dynamic team structures (common in matrix organizations) then function points make sense.  If size is used by a team for its own use and the team structure fixed then story points can be very useful.

 


[1] There are several international function point standard including IFPUG, COSMIC and NESMA.

Function points measure the size of a project, like square feet measures the size of a house.

Function points measure the size of a project, like square feet measures the size of a house.

What are IFPUG Function Points? IFPUG Function Points (there are several non-IFPUG variants) are a measure of the functionality delivered by the project or application.  The measure is generated by counting features and functions of the project or application based on a set of rules. In this case, the rules for counting IFPUG Function Points are documented in the IFPUG Counting Practices Manual. Based on the published rules, the measure of IFPUG Function Points is a consistent and repeatable proxy for size which can be used in estimating and measurement. An analogy for the function point size of a project is the number of square feet of a house when building or renovating. Knowing the number of square feet provides one view of the house, but not the other attributes, such as number of bedrooms.

IFPUG Function Points (or any of the variety of function points) do not measure all aspects of software.  Software projects and applications are combination of functional requirements (what the software does), non-functional (how it does it) and technical requirements (with what). Using our house analogy:

  • Functional: House, 4 bedrooms, 5,000 Square Feet
  • Non-functional: Cedar siding, Red
  • Technical:  Cooper pipes, Slate hall tiles

IFPUG Function Points count the each incidence of the five types of components that most if not all applications have.  In projects, the unique components that are added, changed or deleted (by any means) are accounted for. In an application count, all unique incidences of the five components are counted.   In a project the counting process (in a nutshell) begins by identifying the component, ensuring it is unique and then determining the size.  The Counting Practice Manual provides a set of rules to make the counting process as painless as possible. The five components are:

Data Functions

  1.  Internal Groupings of data called Internal Logical Files (ILF)
  2.  External Groupings of data or External Interface Files (EIF)

Transaction Functions

  1.   External Inputs (EI)
  2.   External Outputs (EO)
  3.   External Inquires (EQ)

The IFPUG Counting Practices Manual includes rules for recognizing and determining the sizing each of the component.

IFPUG Function Points are a representation of the size of software delivered in an application or project. The size is based on a set of rules that can consistently applied by trained counters. Studies have shown that functional size is a good predictor of effort, cost, quality and duration (see any of Capers Jones’ books). As a result, they have been incorporated into many commercial estimation tools.  Agile proponents have some issues with functional metrics, for instance, the perceived overhead of counting functional metrics and the evolutionary nature of Agile projects. Quick and Early Function Points, FP LiteSM and other abstractions of the functional metrics are mechanisms to overcome the overhead criticism and which facilitate quick, repeatable counting, which can be used in evolutionary projects or with lean techniques like Kanban that have granular stories.