6 tips for handling technical stories

The value of vertical user stories seems to be quite familiar for the industry — create small slices of functionality from the users’ point of view, instead of writing horizontal “stories”, that cover only one component of your software.

However, there are times when these vertical slices just don’t seem to be enough. For example spiking new technologies, setting up development environment, enhancing the test framework, improving security, doing major refactoring work… you name it. Here are my tips how you may want to handle these kind of things in your project.

  1. Don’t try to force everything into a vertical story. Based on my experience, having everything as vertical stories is an idealistic state, which in practice isn’t possible to achieve. It’s like defects — you don’t want them, you fix them, but in practice you know that totally defect-free software isn’t possible.
  2. Prefer vertical stories. Having said #1, there is huge value in vertical functional stories, and by default you should always use them. It’s hard at times. If you fail, try harder. Non-user tasks should be used as a last resort.
  3. Have separate metrics for vertical stories and tasks. Whichever tool you’re using, have different issue types for vertical stories and non-vertical tech tasks and measure them separately.
  4. Consider time spent on technical tasks as cost of doing business. If your team isn’t familiar with needed technologies, it probably needs to spike them. Or if there are flaws in the test framework, you may need to spend time improving it. In a way the time spent on technical tasks is a property of the system, and in the course of time it should go down.
  5. Make it visible. For me, the issue with having everything done as a by-product of a vertical story is that it isn’t visible. If you encounter a major refactoring need when implementing a vertical story, one possibility is to do the refactoring  within the story, but then it’s not visible by any means. I’d prefer doing the work in separate task to make it more visible for the team.
  6. Express technical tasks in story format (if you want). You can express technical tasks in story format, if it fits your world and vocabulary. As a tester I need xxx to be configurable so that I can implement test yyy. Remember that these are not user stories, you’re just using story format. And by that I mean that those tasks don’t deliver value to the end user, they are just enablers for the “real” stories.

I do agree with Ron Jeffries that the code should be gradually improved by each vertical story, but in addition to that, there is a need for technical tasks. And there is nothing wrong in using story format in describing those tasks.

Leave a Reply

Your email address will not be published. Required fields are marked *