5 Minute DevOps: Pointless Estimation

Several years ago, I posted “You Don’t Need Story Points.” I said, “Just make things small.” One thing I neglected to do was explain how. Here’s how we did it.

tl;dr: Use BDD and stop wasting time fantasizing about fake numbers.

Background

We were trying to implement a continuous delivery workflow. Many people think CD means we get an automation tool and build pipelines. That’s partially true. The other 90% of CD is how we do everything else. Part of that is learning how to do continuous integration.

CI means that everyone on the team is integrating their work with everyone else’s on the trunk at least daily and verifying that nothing breaks. It’s the central practice of any high-performing team. We had no idea how to do this. Anyone can integrate code daily. Doing it without breaking things means you need to have all of the tests in place, too. However, the way we worked upstream of coding meant there was too little information in the acceptance criteria to write tests before we built anything. so we would build something and ask the product owner, “Is this the rock you wanted?” This resulted in a lot of rework and, usually, no time left for writing the missing tests. You cannot do CI that way.

To fix it, we had to re-think our upstream processes.

Certified Agile Estimation

Our previous process was what the agile consultants taught us. The PO would write user stories with acceptance criteria, and then we would go into story planning. There, we played planning poker, where everyone showed a card for their individual estimate. If someone was an outlier, they would be asked to explain why. This put people on the spot. People don't like that. Usually, they would fall into line with the crowd. Other times, debates would drag on about “Is this a 3? A 5? An 8?” My favorite was the drive-by scrum master saying, “If it’s 13, you need to split it! Make sure it meets INVEST!” Ok…

Once we’d convinced ourselves it was X points, we’d declare it ready to start and then do the next Certified Agile Methodology practice; we’d prioritize according to size.

None of this added business value.

Agile Rehab

For continuous integration to work, we need to be able to deliver tested code. That means we know what we intend to deliver before we start coding. It means that, even if a developer doesn’t do test-driven development, they have the information available to enable it and that the tests are part of the same change: test during development. The requirements were the defect. We had to improve our story refining.

We discovered Behavior Driven Development. BDD revolutionized our workflow. Instead of receiving stories with acceptance criteria from the PO, we worked with the PO to define acceptance tests. These covered the positive and negative behaviors for each story.

Feature: As an hourly associate I want to be able to log my arrival time so that I can be
paid correctly.

Scenario: Clocking in
Given I am not clocked in
When I enter my associate number
Then my arrival time will be logged
And I will be notified of the time

Scenario: Clocking out
Given I am clocked in
When I enter my associate number
And I have been clocked in for more than 5 minutes
Then I will be clocked out
And I will be notified of the time

Scenario: Clocking out too little time
Given I am clocked in
When I enter my associate number
And I have been clocked in for less than 5 minutes
Then I will receive an error

In this example, we can prioritize delivering the first two scenarios and follow with the third later because all three aren’t needed for the feature to be usable. We have plenty of information to create unit tests directly from the requirements. We can make API decisions from this. We also have the ability to split this story into smaller tasks that the teams can collaborate on in parallel that will integrate cleanly. This last was another process improvement we made.

After refining each feature with acceptance tests, we would do a technical decomposition, discuss any service API changes that were required, and define and prioritize the development tasks. Because we were using a pull system for work, everyone was motivated to make the tasks clear because anyone might get any task; we always pulled from the top.

Results

Working together to decompose the work into user-centric acceptance tests spread business and testing knowledge. Setting a hard limit of two days was very effective at shining a light on assumptions that would have delayed delivery or injected defects.

Because we were driving down our story sizes and improving our testing, we delivered higher quality and could get faster feedback on what we delivered. The level of test automation protected us on several occasions when we were trying to respond quickly by stopping bad changes before they could get into version control. We stopped wasting time debating story points. Instead, we debated business value.

We had a lot of things NOT delivered. We wrote the acceptance test, talked about the business value, decided it was a bad idea, and erased it from the whiteboard. There are no bugs where there is no code.

Finally, the team was happier. We were no longer using Fear Driven Development.

The last metric I saw from that team after I left the area was their average cycle time was 0.89 days from when development started until running in production.

Stop Story Pointing

Story pointing and all of the ceremonies around it are still widely taught in Agile Certification courses. People who have moved past crawling abandoned the practice long ago. The only reason others still use it is that they have been solving the wrong problem. They are working on how to do the ceremonies better instead of how to deliver better value. Focus on the business goals, identify roadblocks to daily value delivery, and fix those. Now you’re agile.