Monthly Archives: January 2014

Lifehack: how to improve your memory

Sorry, I don’t know how to improve your memory.  But I do have one tip:

The best way to improve your memory is to organize your life so that you don’t need to use your memory that often.

I know the world is full of different reminder apps and todo lists and such.  For me, the problem with those is that I always forget to use them.  They don’t become natural part of my life.  My “trick” (which probably is common knowledge) is to inject reminders to my everyday life and tools that I already use.  A couple of examples:

  • It’s evening.  Suddenly it occurs to you that tomorrow you need to take the tax card to work.  Solution: place the tax card in front of the front door so that you cannot leave from home without noticing it.
  • Email is natural part of my life.  I often send email to myself.  For example  when work related idea comes to mind during weekend, I send the idea to my work email and then it’s off my mind.
  • Weekend is coming and you are in the middle of some programming task.  How to remember where to continue on Monday?  Leave a non-compiling line in the code so that compiler will remind you where you were.

You get the point!  I’d appreciate to hear if you, my dear reader, have got tips like these.

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.