Boosting team productivity with shorter, testable user stories

By Gai Tamir, VP of R&D, Leverate

When you are a high tech company, innovation is your bread and butter.

For us in the FinTech industry, innovation is ripe, low-hanging fruit and we have the ability to constantly evolve and improve our systems in order to deliver the best products to our customers. Whether it is improving processes often unnoticed by the end-user, to changing the color of a button, to a complete revamp of an entire system, a good, streamlined process of development is key to ensure innovation does not hinder our advancement or our client’s day-to-day operation.

At Leverate, we have been “doing” Agile for 4 years now. Practicing Agile is an ongoing learning process and one thing we’ve learned is that finding the right process is not a onetime effort.

We currently have 6 teams working on 15 different products. Each team includes DEV, QA and Product people.

Our teams use either SCRUM or Kanban in their development process. Each team has its own challenges and all are constantly learning and evolving in order to increase their productivity and achieve their goals.

It is important to look at the issues we were facing and I would like to share my personal thoughts on how to tackle them.

Problems we are trying to solve

Some of our stories are just too big or too complex. Our Product Managers are trying to keep their stories small, but we still find ourselves working on stories that take around 10 days to be completed.

Big stories also tend to get complicated since it’s really hard to identify every possible issue that may arise, no matter how much time you spend analyzing them.

The cost of identifying design gaps after a week of implementation is quite big and is something that happens (at least for us) a bit too often.

Big stories are usually being split into smaller technical tasks that can be handled by multiple team members. Creating, tracking and synchronizing these technical tasks add additional overhead for the team to handle especially when working with distributed teams.

The general rule for splitting stories states that every story should provide business value. I personally believe that this is a very hard requirement to meet, but more on this later.

The teams spend too much time in backlog refinement (or grooming) meetings. For a mature team this is a major productivity killer which often feels unnecessary and usually caused by the team’s tendency to focus on effort estimations instead of on the details of the task at hand.

Some of you may have already heard about the big debate going on under the #noestimates hashtag as to whether we should estimate at all.
This is somewhat related to the contents of this post, but it goes beyond the scope of what we’re doing right now so I’m not going to focus on that, but I did recently bump into this short summary of the origin of the #noestimates wave and its current state, in case you want to learn more on this subject.

Suggested solution: Short, testable stories

We defined a new “rule” stating that stories should not take more than 2-3 days to be completed, including testing and any other steps which are part of our “definition of done”.

We are willing to accept the situation where a story does not necessarily add business value to the product as long as it’s testable. We believe the benefits of making such a compromise outweighs the costs.

A very short story does not require additional splitting into tasks, so going back to the point about management and tracking complexity, instead of using the Feature → Story → Task hierarchy, we now only have this one: Feature → Story which is much easier to handle.

Backlog refinement meetings no longer include the Poker Planning phase. Instead, the team confirms that the story is short enough or request that the story will be split into smaller stories.

You can argue that by limiting the story’s size we’re basically estimating. That’s ok with me. It still saves us a lot of meeting time since it’s a lot easier for the team to understand the story’s details.

Since each story is so small the discussion tends to focus around the feature instead of the story which for me is another great benefit. It makes sure everyone understands the “What we are trying to achieve” rather than the “How we are going to achieve it”.

Most story-related discussions are now part of a story implementation kickoff session which is a short, ad hoc discussion between the people actually working on the story. It’s also very hard to miss things when you split your stories into such smaller pieces, and even if you do, the cost of adjusting your path is super small.

Obviously there will be situations where it’s just not possible to split the story into a 2-3 day timeframe (major refactoring efforts, for example) but it will usually be the exception that proves the rule.

One thing that will happen immediately is that the throughput of stories going down the pipeline will be a lot higher. Even if the feature average lead/cycle time remains the same, the benefits of completing small units of work quicker will produce better management and tracking as well as boosting the team’s spirit.

If you’re interested in measuring your velocity, go ahead, just count the number of work items completed instead of counting story points. I guarantee that over time both metrics will produce the same results.