Commitment considered harmful

Disclaimer: This content falls into the realm of Systems Thinking. Systems which include humans are complex and changes to them often result in unintended consequences. As this post covers ‘productivity’ metrics we should tread carefully and remember the warning from Eliyahu M. Goldratt, “Tell me how you measure me, and I will tell you how I will behave.”

Estimating the amount of work that will be completed has always been a controversial topic. In 2011 the Scrum guide was updated and the term commitment was replaced with forecast. Regardless of the terminology, most Scrum teams make a guess as to how much they will do in a sprint, and this is typically reported to management.

There are generally three different techniques teams use for deciding on the forecast . A team can use a ‘gut feeling’ and take an educated guess as to how much will be completed. Alternatively a team may take an average of the last three to five sprints and use that as the forecast. Thirdly, there is a technique called yesterdays weather. This is when the actual points delivered in the previous sprint are used as the forecast for the next sprint. I have concerns about all three of these approaches. I feel that all of these approaches lead a team into overcommitting.

When teams use their ‘gut feeling’ they are subject to a number of biases. There is the planning fallacy which is the tendency for people to underestimate how long it will take to complete a task, even when they have done similar tasks before. Hofstadter’s Law states that “it always takes longer than you expect, even when you take into account Hofstadter’s Law.” On they point out that motivated teams naturally set higher goals for themselves, however this does not always result in an improvement.

It’s human nature that individuals and teams with self-esteem set increasingly higher goals for themselves. By trying to achieve these goals, teams learn. Sometimes such strivings leads to immediate improvement, particularly when the team challenges itself to improve through use of a new-found technique or technology. Sometimes, however, the new technique doesn’t pan out and the team’s performance remains the same or even gets worse.

Sometimes, the team raises the bar just to raise the bar, either to test the limits or to unconsciously publish its bravado. Even these self-challenges can pay off, especially in the short term. It is more common that these higher levels are unsustainable in the long term.

Therefore: In most cases, the number of Estimation Points completed in the last Sprint is the most reliable predictor of how many Estimation Points will be completed in the next Sprint.

The quote above ends with recommending yesterdays weather as the most reliable way to forcast the work that will be done in the next sprint. Unlike using your ‘gut feeling’ with ‘’yesterdays weather’ the team can’t simply choose a high velocity (potentially hiding from reality). In order to get a high commitment, you need to have actually delivered a high amount in the previous sprint.

This may work for mature teams with stable platforms, it may however be less successful when there are many disruptions e.g. changes in personal, many technical unknowns, unpredictable development and test environments e.t.c. The following diagram is data taken from a real project. It shows actual delivery plotted against a retrofitted forecast based on yesterdays weather. In this case the team would have met the goal ~52% of the time. This may not be consistent enough for the teams planning needs and this success rate may negatively affect the teams motivation over time.

ForecastYesterdays Weather

Forecast based on ‘Yesterdays Weather’

Note: The forecasts\commitments have been retrofitted to the graph. The team may have had different results had they used yesterdays weather during planning.

If the actual velocity is varying enough to make yesterdays weather unreliable, a team may decide to take the average of the last few sprints (typically 3 – 6 sprints). If we consider the definition of average, this means that about half of the actuals will fall above the average and about half will be below. Statistically speaking we only have a 50% chance of meeting the forecast if we base this on the average.

A retrofitted forecast based on the total average

A retrofitted forecast based on the total average, means that the commitment is met 50% of the time

A retrofitted forecast based on a rolling average of 5 sprints

A retrofitted forecast based on a rolling average of 5 sprints, means that the commitment is met 46% of the time

Due to the reasons stated above I believe that these, well intentioned, forecasting techniques may lead a team into over committing on a regular basis. Not only does this make release planning and budgeting difficult, overtime this can have a detrimental effect on a team. Team members may stop caring about meeting the commitment and sprint goal. This can result in a general lack of motivation. If your team is suffering from this, you may want to try using a control chart to help you set realistic forecasts.

Control Charts1

Control Charts are typically used to determine if a manufacturing or business process is in a state of statistical control. Carl Berardinelli explains that there are four process states (seen above). He states that “every process falls into one of these states at any given time, but will not remain in that state. All processes will migrate toward the state of chaos. Companies typically begin some type of improvement effort when a process reaches the state of chaos (although arguably they would be better served to initiate improvement plans at the brink of chaos or threshold state). Control charts are robust and effective tools to use as part of the strategy used to detect this natural process degradation”.


The following link shows children explaining how Flowcharts and Control Charts are used at their kindergarten.

Above is a Control Chart derived from a teams velocity

Above is a Control Chart derived from a teams velocity. The dark blue line is the actual velocity over the past 29 sprints. The grey (gray?) line represents the average actual velocity. The red lines show the Upper and Lower control limits. These are plotted at one standard deviation from the average.

Continue reading


Tutorial – BDD and Dependency Injection in .Net (3)

In part 2 of this tutorial, we moved the decision logic out of the Game class into the Decision Engine class to separate concerns. Now we introduce dependency injection.

In this part of the tutorial, we will use dependency injection (DI) to improve the design of the code base. Zby provides a useful definition of dependency injection: “Dependency injection means giving an object its instance variables instead of letting it create them”.

In our case, we will be giving the Game object an instance of Decision Engine instead of letting the Game object create it itself. We will do this via the Game’s constructor, however it could be done though a property or a method. These alternatives are known as constructor injection, property injection and method injection respectively.

This is the essence of the dependency injection pattern. Confusion tends to creep in when a dependency injection container is introduced. DI containers, such as unity or Castle Windsor, provide mechanisms to aid in implementing the dependency injection pattern. However, they are not required to implement the pattern. I recommend the use of DI containers when the benefit of using one outweighs the complexity that is introduced by using it.

For the sake of simplicity, I will be using the dependency injection pattern and will avoid dependency injection containers for the time being. Returning to the rock, paper scissors example, DI will provide two main benefits:

  • Flexibility – we will be able to provide different implementations of the Decision Engine without changing the Game class. This ‘pluggable architecture’ adheres to the open close principle. An example of this would be a decision engine that not only decides on a result, but also logs the results to a data store. I will return to this should time allow.
  • Testability – during testing, we will be able to pass a mock object to the Game object, thus allowing us to test the Game class in isolation of the Decision Engine. This will be demonstrated in the code below.

Continue reading

Tutorial – BDD and Dependency Injection in .Net (1)

This tutorial focuses on Behaviour Driven Development, Dependency Injection and application design in general. The primary technologies being used will be SpecFlow and MS Test. While we are targeting the .Net platform the content is applicable to most object oriented languages.

A Brief Introduction to Behaviour Driven Development

Behaviour Driven Development (BDD) is an ‘outside in’ or ‘top down’ development approach. Development starts from the user interface downwards as opposed to starting with the database design.  When there is no user interface (as in the beginning of this tutorial) we work from the highest level possible.

BDD encourages thin slices of work. Where we break features down into very small ‘end-to-end’ pieces of work. This work is expressed in the form of examples. This is known as specification by example and we will see this in the tutorial.

In SpecFlow speak, each example is known as a scenario. We need to implement a number of scenarios before the feature is considered complete. We will flesh out the design as we implement each scenario.

The following diagram from The RSpec Book shows the BDD cycle:

BDD Cycle

As depicted, there are two levels of testing – high level system or integration tests and lower level unit testing. The high level tests often drive a user interface and may be referred to as automated acceptance tests.

Not only will we be following the BDD cycle, but we will only implement the code we need to make the existing tests pass – and no more. We will be very strict with this. This may seem tedious to some however this approach is good to practice. You can always fall back to this approach should you become stuck when writing production code.

Interestingly TDD was always meant to have multiple levels of testing. In Extreme Programming Explained, Kent Beck and Cynthia Andres have the following to say about architects: “Architects on an XP team look for and execute large-scale refactorings, write system-level tests that stress the architecture, and implement stories”. This is similar to what we are trying to achieve in BDD. In fact Dan North introduced the term BDD to help him explain TDD to developers. This is why I say that BDD is TDD done properly.

These days it is common to hear teams say they are doing “TDD but not BDD”. By this they sometimes mean that they are writing system tests and unit tets, but they are not using a “BDD testing framework” like Cucumber or FitNesse. There is nothing wrong with this approach. Sometimes “we do TDD but not BDD’ means that the team members are not writing system level integration tests. This is better than no tests at all, however it is not true TDD and they are missing a trick.

A Brief Introduction to Dependency Injection

James Shaw does a great job of explaining Dependency Injection (DI). He points out that “Dependency Injection means giving an object its instance variables”. The instance variables are typically reference types which provide a layer of abstraction. We can give an object it’s instance variables through a number of different ways namely constructor injection, property injection, method injection.

There are many reasons for using Dependency Injection. The most obvious reason is that it makes the code more testable. It makes it easy to use mock objects in place of the real dependencies during testing. Testability is not the only reason, when done properly code which uses dependency injection tends to support the SOLID design principles, most notably the Single responsibility principle and Open/closed principle. This will be shown in the tutorial.

Dependency Injection is a simple concept, the confusion seems arise when Dependency Injection containers enter the discussion. For this reason I will not use DI Containers for the first few parts of this tutorial. All I will say is that DI Containers may help when composing objects, however they are not required to implement the dependency injection pattern.

Continue reading

In Theory and In Practice

We recently completed a small but interesting project at work. The team consisted of Tim Weeks, Lee Walton and I played a supporting role. We shared the lessons learned in an experience report at the Agile Practitioners group. The talk was filmed and can be seen below.

On this project, the developers tried a number of Agile and XP practices. BDD and Pair Programming were tried for the first time, in the video they explain what this was like.

In addition to the Agile aspects, the talk shows what Lean (kanban) principles we followed e.g. making decisions at the last responsible moment.

There is a large section on using code reviews and code metrics to help improve code quality.

I got off to a shaky start, but things seemed to improve as the video goes on.

Part 1:

  • Overview of the project
  • Developers discuss how they felt on the project
  • Discussion on pair programming for the first time
  • The importance of putting people first
  • NUMMI case study (GM and Toyota)
  • Start of project – beginning with the end in mind
  • Re-writing stories, to remove implementation details
  • Simplicity – the art of not doing work
  • Cost of defects
  • Concurrent development
  • Making decisions at the last responsible moment

Part 2:

  • Burn down charts
  • Cumulative flow diagram
  • Walking skeleton or tracer bullet
  • Lean thinking – limiting work in process
  • Pull System
  • Dealing with blocked stories
  • Code Reviews (brief discussion)
  • Relationship with PO – developers having access to users
  • Task switching – cost of task switching on projects

Continue reading


The Agile Practitioners group recently held a pecha-kucha event at Zuhlke Engineering. The talks were great! The content was intriguing and the Pecha Kucha format added an extra edge to the presentations.

We learned a few lessons that will help improve the next Agile20x20 event.

Here are the talks

Christian Heldstab does a great job of presenting Getting Things Done

Abid Quereshi exlapins the core values of Scrum

Continue reading

The Buffering Law observed in Software Engineering

Railway buffer at the top of Pikes Peak, Colorado Springs CO

There is an informative slide deck on the FactoryPhysics website entitled A Fast Cycle Time Story. This slide deck was created by two Intel Products employees namely Tim Skowronski and Joan Tafoya.

The slides cover many aspects of lean manufacturing, one of the topics covered is The Buffering Law

Systems with variability must be buffered by some combination of:

  • Inventory
  • Capacity
  • Time

Tafoya and Skowronski explain the implication of this law

If you cannot pay to reduce variability, you will pay in terms of high WIP, under-utilized capacity, or reduced customer service i.e. lost sales, long lead times, and/or late deliveries.

The following variability buffering examples are provided:

  • Ballpoint Pens:
  • can’t buffer with time (who will backorder a cheap pen?)
  • can’t buffer with capacity (too expensive, and slow)
  • must buffer with inventory
  • Ambulance Service:
    • can’t buffer with inventory (an inventory of trips to hospitals?)
    • can’t buffer with time (response time is the key measure)
    • must buffer with capacity
  • Organ Transplants:
    • can’t buffer with WIP (perishable – very short usable life)
    • can’t buffer with capacity (we cannot ethically increase capacity)
    • must buffer with time

    Continue reading

    The X Penny Game

    The X Penny Game is a simulation game exploring the effects of WIP limits. It is a combination of Karen Greaves modified Scrum Penny game with Karl Scotland’s version of the Ball Flow Game.

    This game is geared to show the importance of limiting the work in progress and to explore the following formula (implied by Little’s Law)

    Flow Time = WIP/Throughput

    • Flow Time (Cycle Time, Lead Time) – average amount of time it takes to fully complete a unit of work
    • WIP (Work In Process) – is the average amount of units in the system
    • Throughput – average number of units being completed within a given time frame

    The game is designed to work with 6 to 12 people – we had 8 players and 1 facilitator

    The team divides into the following roles:

    • 1 – Customer
    • 5 – Workers
    • The rest are efficiency experts

    We had a total of 8 players (6 workers, 2 efficiency experts).

    The team organises themselves around a table. The image below shows how our team arranged themselves. Each worker has an empty area on the table directly in from of them referred to as a workspace.

    Continue reading