From Story Points to Test Driven Development – A Dev Team Story

By Rebecca Schira

I’ve been supporting agile teams for almost six years. What is the one common issue I’ve seen across many teams and two companies during that time? Everyone loves story points or at least proclaims to love them. But why? The common answers we’ve all heard -they’re easier to understand, they’re a good way to do a gut check, etc. Without fail, each and every one of these teams sucked at estimating how much work they could accomplish.

One of the first things I learned as a Scrum Master is that small changes were the best path to team success, and forcing change on anyone just leads to more failure. When the company I was most recently with decided that we should move away from Story Points as a corporate mandate, every team pushed back. “We’re supposed to be autonomous!” was the cry heard around the office for days following. There was a level of resistance that I would’ve expected given forced change, especially because it was not gradual. I promised my team that we wouldn’t drop story points (I might have stretched the truth a little) but slowly started them on the path to being free of numbers.

First, it was as simple as during a retrospective, I’d show them their velocity as they’d normally seen it (how many point were finished vs. committed) showing them that they hit their usual 30 points (even though they consistently committed to 40-45, can’t fault them for being optimists!), which the PO was more than happy with since he always knew what work to expect out of them. Next, I brought in a new tool that would start changing the conversation – Throughput.

As you can see above, the team usually completed about 62% of their stories from sprint to sprint. Next, I started talking to them using the number of issues completed instead of the velocity as we continued. Instead of 30 points, the conversation became 12 stories, were completed. Needless to say, our developers were the first to exclaim “They’re getting done within 14 days, we get them over to QA!” As we dug into the data we started noticing a pattern. No matter the number that was thrown on a story during sprint planning, stories were taking at least six or more days to get through development (some were less, but they were in the minority). After two sprints of looking at this, we ended up in what became a very long and heated retro. We decided there might need to be a change.


The first, and hardest, change they made was to begrudgingly drop story points. The team decided to take a chance on using risk to determine if a story was ready for acceptance and just count issues (first small win). The second change came directly from the first. After two sprints of most stories having too many risks to be comfortable to commit to, they realized that they needed to start planning ahead more. They started asking their most experienced developer to start working with the PO to define the Feature work ahead of time so that it would be ready for the team to assist with a breakout of the user stories. They changed their definition of ready from “Story is clear and has acceptance criteria” to be much less vague. First, all stories required a check for any research enablers that were required to start. Next, they took it a step further and started working on feature level design documentation to help drive story creation, and calling out the research needed before any stories were even started. All of this led to decreased dev time, increased issue completion rate (they went from around 10 issues per sprint to 15), and a better flow to their work, which increased their predictability (which was a huge win as we’re moving towards a quarterly release cadence). At this point, we’re up to around a 75% completion rate. The only nagging issue the team had was that pesky “final step,” QA…

We’ve been making these small changes sprint to sprint, increment to increment, over almost nine months. The team (mostly) feels great! They’re hitting most of their commitments, and morale is great. They just can’t seem to make that final push over their self-set goal of 80%. As we rolled into a new increment, they knew they would be working on a brand new feature. They had to build in automation, which had always been an afterthought in their legacy product work. I suggested some changes that had been brought up by the testers in the past and the developers (the same ones who refused to drop story points nine months earlier) started feeling like the sky was falling again. The simple idea the testers had? Test-driven development (at least their approximation of it). Apparently, this is a scary phrase to developers, who knew? So, as a first exercise to dip their toes in the water, we agreed that the testers would come into to Feature planning meeting with the developers and start writing their own design document, only instead of looking at it from the developers’ perspective, they were looking at it from the perspective of a tester (and coming from a test background myself, I know how different this can be). Instead of seeing the problem in one simple solution, they started looking at the problem as something that would be broken by users this way or that, by a new system admin by clicking the wrong box. They knew the issues the legacy product this was going to replace had and made sure to call out to avoid those same things. They asked why we couldn’t write automated tests into the new code as it is being written. “This way we know if we broke something when we make a change later without having to do 20 hours of regression” was the rallying cry of the testers. Slowly the developers relented, and so far our experiment has borne fruit.

Do they consider themselves a finished product now? No! They’re spending more time digging into the realm of TDD as we prepare for a new increment, on yet another new product. The future for them is success though because the one thing they’ve gained is the realization that holding onto something just because “we’ve always done it” isn’t going to bring about success in the future.


Rebecca Schira can be reached via LinkedIn  One parts of my career that I take great pleasure in has been getting to know smart cool people like Rebecca.  Start a conversation with her, you will enjoy it!