Technical Tasks vs. Stories
A lot of teams have trouble deciding whether a task should be declared as a technical task or a story. The simple answer here is that if a customer can ask for it, it should be a story.
For example, the following should be stories:
– Creating an installer – “As a customer, I want an easier way to install the application”
– Supporting an incremental DB tool (such as Liquibase) – “As a customer, I want an easier way to the application database when upgrading software releases”
– Supporting a new deployment environment – “As a customer, I want to be able to run on a 64-bit HP box”
– Improving the system performance – “As a customer, I want to run WizBang transactions faster (i.e. denormalize WizBangFoo and WizBangBar database tables)”
The following should be technical tasks:
– Refactor the new domain objects to eliminate duplication
– Make sure that PMD and Clover are running with the nightly build
– Run a continuous integration build
– Test integration between FooServer and BarWebService
Just because something sounds technical (like improving performance or supporting a new DB tool) doesn’t mean that it can’t be captured as a story. The problem with not capturing customer requirements as stories is that it becomes unclear when they should be prioritized. Who gets to decide? The team lead? The product manager? The architecture team? The project manager? The team? The receptionist?
The other problem is that you don’t get credit for the work and effectively devalue the stories that you are working on in the iteration in which you take on the (miscategorized) technical task.
Take a closer look at the tasks that you have sitting on a punch list or task board somewhere and see if it could be asked for by a customer. If so, write it up as a story and hand it over to your product manager.