technical story

Technical Stories – How to Work Them

I was perusing some blogs and I came across a discussion regarding Technical Stories on Jack Milunsky’s AgileBuddy blog.  The focus of the blog is whether or not Technical Stories should be included in the Product Backlog.  Jack does a good job presenting both sides of the argument, and in the end leaves it up to the reader to assess their individual products/projects.

In my recent experience at a software company that produced infrastructure products, it was not unusual to negotiate technical stories into the sprint.  However, this was easy to do because we were producing an enterprise infrastructure product where the primary user story might be “As a B2B administrator, I need to support over 1MM 50Kbyte transactions per day so that I can support the business growth.”  We would then have subsequent stories and tasks that support building a test harness, securing/procuring hardware, and executing various tests.  In addition to technical stories that satisfy core needs of the product, we also maintained a separate backlog that was focused on those things that improve the quality, maintainability, and supportability of the product.  Our product team was not huge and we were often charged with working a large amount of level three support, so for every couple sprints we would rotate team members into the role of level three support.  They would then assist with customer issues as well as work our technical story backlog.

So, having technical stories worked for us; however, I can see how they can get in the way of focusing on getting a product out the door and gaining the value as early as possible.  I share Jack’s opinion — do what works for you, but here are some key points to remember when considering whether or not to include technical stories in the backlog.

  • Educate and keep your Product Manager/Owner in the loop when it comes to technical stories. Most of the time, technical requirements are embedded in user stories.  In some cases it makes sense to pull out these technical requirements as stories because they may increase the product value in the customer eyes.
  • Assess whether or not a technical story should actually be a task associated with a user story with clear business value.  In most cases, a technical story could be a task associated with delivering a user story.
  • Maintain a separate backlog to house technical stories.  These stories should be worked by dedicated team members or at least with some level of dedicated capacity.
  • Incorporate what someone might write up in a technical story into done criteria and or the story’s acceptance criteria.  For example, enhancing the continuous integration environment, incorporating functionality into the nightly automation cycle, or verifying the new functionality is properly installed.