Probability, Velocity and Re-Estimating User Stories

When working with user stories, story points and SCRUM, it is not uncommon to come to the end of a sprint and realize that a smaller story took longer to complete than a larger story. While this is an excellent reminder that story points reflect complexity, not effort, it is often misinterpreted as an indication that remaining stories need to be re-estimated. Basic probability distribution shows us that over a large enough sample, all three point stories in the product backlog will take about the same time to complete. A team’s desire to re-estimate stories in the product backlog based on a few stories deviating from the norm is a mistake.

Not All Stories are Created Equal

If you were to roll a pair of dice a million times, you would see the majority rolls sum up to seven. If you graphed the data, you would see a bell curve shape. User stories are no different.

Over a large enough sample, you will start to see the same bell curve shape in the time it took to complete those stories. Some three point stories might take two hours to complete while others take twelve; but most take seven. At the same time, some of your five point stories will take ten hours to complete and some twenty four; but most take eighteen. Consider the overlap in the following diagram:

The overlap between the time to complete some of the three point stories and some of the five point stories should not be mistaken for a need to re-estimate any stories. Sometimes a three point story will take as long to complete as a five point story.

Commitment Driven Planning

One technique from which all SCRUM teams could benefit is that of Commitment Driven Planning. From Cohn’s Agile Estimating and Planning

A commitment-driven approach is an alternative way to plan an iteration. Commitment-driven iteration planning involves many of the same steps as velocity-driven iteration planning. However, rather than creating an iteration plan that uses the yesterday’s weather idea to determine how many story points or ideal days should be planned into the current iteration, the team is asked to add stories to the iteration one by one until they can commit to completing no more.

So what happens when a three point story is tasked out and comes to ten hours, and a five point story is tasked out and comes to nine? Often times the first inclination of the team is to inflate the three point story. Especially interesting is that almost no one suggests to shrink the estimate of the five point story. Again, we should expect that some three point stories will take the same amount of time to complete as some five point stories, but in the end this will even out.

Velocity is The Great Equalizer

Again from Mike Cohn’s Agile Estimating and Planning

What’s happened here is that velocity is the great equalizer. Because the estimate for each feature is made relative to the estimates for other features, it does not matter if our estimates are correct, a little incorrect, or a lot incorrect. What matters is that they are consistent. We cannot simply roll a die and assign that number as the estimate to a feature. However, as long as we are consistent with our estimates, measuring velocity over the first few iterations will allow us to hone in on a reliable schedule.

As the team complete more and more sprints, developers will come across three point stories that are a little larger than average and five point stories that are a little smaller than average. Between our bell curve distributions and velocity acting as the great equalizer, over time, the bumps in the estimations will smooth out and the desire to re-estimate stories will fade.

Agile Principles: Iterate. Evaluate. Repeat

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
The first thought here is the means, the second the end. Let’s start with the second.


We want to afford the customer the ability to adapt to rapidly changing markets. Processes that restrict the customer’s ability to adjust the implementation strategy of their vision make it impossible to use change as a competitive advantage.


Focus on current priorities, delivering value with a consistent cadence. As you iterate, allow for the customer to evaluate changing conditions in the marketplace.

Iterate. Evaluate. Repeat.

Agile Principles: Deliver Early and Often, but Always Deliver Value

The Agile Manifesto describes twelve principles of agile software. In a series of twelve blog posts, I will explore each principle.

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

This principle can be broken down into two separate thoughts. Continuously delivering early, and always delivering value.

Delivering Early and Often

Delivering early is more than just delivering something before the competition. Delivering early is more than just delivering before you would have had you not been being Agile™. Delivering early means specifically delivering less than you could have otherwise. Continuous delivery and iterative development are synonymous, it is not enough to just deliver early, you need to frequently do so.

Always Deliver Value

Delivering value is difficult. At a high level, it is difficult to know what is and is not valuable. Following the process and being disciplined can get you to a point where you are delivering early and often, but without a unified vision of what you are creating, it is very difficult to deliver real value.

Delivery early and often, but always deliver something of value.

Using Bundler and Capistrano Behind a Proxy

When you’re developing applications for a fortune 50 company, you’re bound to run into a problem with their security focused IT department. Recently, I was having trouble deploying a rails application to a server that was sitting behind a proxy. I tried to solve the problem by changing bundler, then by reconfiguring capistrano, but those were both dead ends.

Setup Your $http_proxy

I thought that I could edit my .gemrc and that bundler would use those settings, but that didn’t work. I had been installing gems by using the --http-proxy flag so it seemed like that would work. I had also been contacting the outside world (for git and other things) by setting the http_proxy environment variable, but I was doing so manually each time I needed it, rather than setting it up in my shell’s rc file. Here’s how I fixed it.

This assumes that the shell you’re editing belongs to the user that deploys the application in capistrano.

1. Add the http_proxy to your shell’s rc file

# bash
export http_proxy=

setenv http_proxy

2. Ensure that when you create a new session, the http_proxy environment variable is actually set

$> echo $http_proxy

Now, when you deploy with capistrano, the bundle command will the proxy that’s setup and communication with your gem sources won’t timeout.

Why Developers Avoid Testing

While the drive towards a culture of “always be testing” has existed for some time, the recent detour into software craftsmanship has helped to create a new style of getting the word out. What used to be, “Test driven development is a great way to approach solving a problem” has turned into “If you’re not testing you’re a shitty developer.” The testing evangelism going on in the community today is misguided and would convert more people if it addressed the real reason people aren’t testing.

It’s Like Losing Weight

To the ever testing software craftsman, it can be puzzling why people don’t write tests. The assumption much of the time is that developers are lazy, that they don’t care about the quality of their code or even that they think testing is an abject waste of time. In my experience this is almost never true.

People skip testing because, ultimately, it’s hard work. Think about what it takes to lose weight or to quit smoking:

  • Break familiar habits
  • Disrupt your personal relationships
  • Acknowledge that you’re deficient
  • Find help
  • Fail often before you succeed

As a developer working in an organization that does not maintain a culture of “always be testing”, it’s going to be difficult to:

  • Change the way you think about solving problems
  • Upset peers who are comfortable in the status quo
  • Admit that you don’t how how, what, when and why to test
  • Find a mentor willing to help you improve
  • Not give up every time you get stuck

End the FUD!

Think about what it means to start testing when you never have before. Not only do you have to come to terms with not knowing what you’re doing, you eventually realize that you’ve been “doing it wrong” until now. This is fearful self-doubt territory for a lot of people.

If you’re serious about getting more of your industry peers to start testing, stop:

  • Going on about craftsmanship; people don’t strive for mediocrity.
  • Playing the doomsday “If you don’t test…” game.
  • Talking about how testing makes you so much faster; their personal experience points to the contrary.
  • Overlooking their perception of testing.
  • Forgetting when you were in their shoes.

Instead, ask questions, get to the root of the problem, don’t settle for “testing makes me slow” or “that’s not my job”, dig deeper.

I believe that as an industry we should strive for increasing code quality, robust test suites and better problem solving. As the minority who are practicing TDD/BDD/test-first/TATFT etc., we need to change our tune. Let’s stop preaching the benefits and start addressing the fear, uncertainty and doubt that keeps smart, capable and dedicated developers from enjoying these benefits.

Let Conversations Write Your Tests

I consider myself an early adopter of Cucumber and have spent a lot of time using, thinking about, writing about and discussing cucumber and, at a higher level, behavioral driven development. Lately however, I’ve really been rethinking how I use Cucumber and why. Am I getting enough benefit from the overhead and abstraction of plain text features? Could I do the same thing with RSpec if I just approached RSpec differently? Am I cuking it wrong?

This shift in thinking is due in part to Liz Keogh’s Step Away from the Tools and Dan North’s Who’s domain is it anyway?. Both of these got me thinking about how I’m using the term BDD (rather loosely) and how much of an investment I’m making in a specific tool (Cucumber).

More Meaningful Planning

Having meaningful planning meetings with their customer/product owner is one thing with which many teams struggle. Too often, we go too fast, don’t uncover enough detail, use the wrong language, don’t understand “done” and leave too many loose ends.

To combat this we draw screens, discuss workflows, ask leading questions and a variety of other techniques. I felt that while I was doing these things, I was still frustrated with the other part of the planning process. I’ve never liked traditional tasking and I’ve never like the idea of having to translate all of the data gathered with the customer into some other form only to express it later in a test in yet another form.

What if I wrote my tests during the planning meeting?

I decided that changing the way I gathered conditions of satisfaction, defined “done” and discussed workflows with my product owner would give me the biggest boost in value delivered, so one day I did just that.

For the following examples, assume that we’re adding a feature to an e-commerce website.

As a user I should be able to manage addresses so that I don’t have to enter my information more than once

As I’m discussing the feature with my product owner, I will discuss with them the possible scenarios, including workflows, required to use the feature. Some scenarios for this feature might include:

  • When I am on my account page
  • When I am creating a new address
  • When I am deleting an address

These scenarios might have scenarios of their own:

  • When I am editing an address
    • When I successfully edit my address
    • When editing my address fails

So far I’ve been able to ask the product owner something like “So when I’m editing my address, and I miss some required fields, what happens? What do I see? Where do I go? What are the required fields?”. I can also draw pictures to explain the workflows and ask more questions “What’s on this page? Where is the error message displayed? Do I see error messages for the fields that are missing?”.

For each scenario, I can capture assertions that come from answers to the questions I’m asking:

  • When I am on my account page
    • I should see a link to “My Addresses”
  • When I click on the “My Addresses” link from my account page
    • I should be on my addresses page
    • I should see “My Addresses” in the page heading
  • When I am on my addresses page
    • When I have existing addresses
      • I should see each address listed in format xyz
      • I should see an “edit” link for each address listed
    • When I don’t have existing addresses
      • I should see help text explaining how to add an address

If you’re an RSpec user, you might be thinking, “Hey this looks like RSpec!” and it does. During the planning meeting I can capture these scenarios and outcomes and then use them nearly verbatim for my RSpec acceptance tests. Even better, when I run my tests, I can use the “documentation” format that RSpec gives you to output that’s almost identical to the scenarios above.

The conversation required to really define these scenarios and outcomes is challenging, but at the same time, very rewarding. I have also found that it’s pretty powerful to be able to sit with the product owner and view two nearly identical documents side-by-side knowing that one is automated test output.

Desert Code Camp April, 2011

Below are links to my slides and Speaker Rate profile for each of the three talks I gave today at Desert Code Camp.

Ruby on Rails 101

Speaker Rate

Everyday Extreme Programming
Speaker Rate

You Don’t Have to be a Ninja to Learn HTML5
Speaker Rate

Printing PDF HightCharts with wkhtmltopdf and PDFKit

I have a rails 3 application that’s using Highcharts the fantastic javascript powered charting library. I’m also generating PDF versions of some pages using wkhtmltopdf and PDFKit for things like “download this report” and what not.

Everything was working great, until I noticed that my line charts were being rendered very poorly when I was viewing a PDF. As HTML they look great, but as a PDF they look like this:

I dug around a bit and found a helpful forum post explaining the problem, something to do with how wkhtmltopdf renders opacity. The important part is this (specifically line 7):

<script type="text/javascript" charset="utf-8">
  var chart = new Highcharts.Chart({
      chart: { renderTo: 'container' },
      // These make it work nicely with wkhtmltopdf
      plotOptions: { series: { enableMouseTracking: false, shadow: false, animation: false } },
      xAxis: { categories: ['Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun', 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec'] },
      series: [{ data: [29.9, 71.5, 106.4, 129.2, 144.0, 176.0, 135.6, 148.5, 216.4, 194.1, 95.6, 54.4] }]

Turning off animation, mouse tracking and shadows apparently gives wkhtmltopdf enough to render the chart. When I added that to my charts, I got a chart that looks like this:

Cucumber, Culerity and Bundler Errors

I had recently switched a rails 2.3.10 project, that makes heavy use of cucumber and culerity for javascript testing, to bundler for dependency management and immediately started receiving an error like this when I tried to run a javascript test which invoked jruby.

  Scenario: Ability to un-attend an event               # features/events.feature:22
JRuby limited openssl loaded.
gem install jruby-openssl for full support.
    Given I am logged in as the admin                   # features/step_definitions/admin_steps.rb:12
      (eval):1:in `process_result': compile error
      (eval):1: Invalid char `33' in expression
      (eval):1: syntax error, unexpected tIDENTIFIER, expecting ']'
      Could not find rake-0.8.7 in any of the sources
                ^ (SyntaxError)

I searched and searched and couldn’t find a solution. I finally ended up using selenium to avoid this and that has been working okay for a while. Then today I decided to start looking again, figuring that something might have happened in the last few months, and I was lucky enough to stumble across this gist. The author was having a similar problem to mine, except that he was using rspec and steak. His solution was to add some code to his spec_helper.rb file. I added mine to my features/support/custom.rb file so that it would be loaded by cucumber. The fix is:

# Add this to features/support/custom.rb
  ENV['RUBYOPT'] = ENV['RUBYOPT'].gsub(%r{-rs*bundler/setup}, '')

I don’t know exactly what is happening, the only comment in the gist near the fix is suppress '-rbundler/setup' from RUBYOPT, but what’s important is that now my cucumber tests pass using culerity just like they did before.

Do You Make This Common Debugging Mistake?

Hi, my name is Clayton and I use ruby-debug. There, I said it. As a matter of fact, I use ruby-debug a lot, I use it too much. I’m not even solving complex problems or debugging nitty gritty internals, I’m just being lazy. Sure, ruby-debug is a really awesome tool, but we abuse the hell out of it. If you’re reading this and thinking “hey, that’s what I do” then you’re making a mistake, a mistake that’s hurting your code.

How Debuggers are Abused

Marking breakpoints and stepping through your code, evaluating each line and variable is a pretty typical practice. There are some developers who literally figuratively could not live without their debugger. I suspect this is most common in languages where IDEs are prevalent, but lets not forget about the modify-refresh-repeat paradigm in the PHP world.

Sometimes, when I come across some unexpected result or outcome, I will immediately add my debugger statement and start stepping through the code line-by-line echoing variables, assignments and conditionals to the terminal trying to track down my problem. Recently, I had a colleague scoff at the idea of not having ruby-debug for their rails project. The idea that we need this tool for day-to-day development is absurd.

Our One Step Program

When you’re testing the logic and/or output of your code with a debugger you’re making the mistake of not writing automated tests.

There are few problems that are solved via the manual and time-consuming process of a debugger that cannot be solved with an automated test. If you’re confused about the output of a calculation or method, write a quick unit test for that method. When the logic of your application doesn’t appear correct based on the input, maybe an integration test is in order to evaluate the flow of your program.

Not only do you get rid of the debugger baggage, you gain all of the other benefits that go along with testing.

BONUS: Excuse Resolution Table

If you’re getting ready to excuse your debugging behavior, check this list of resolutions first:

But excuse, I need a debugger…

Write more tests. Don’t have tests? Quit your job.