Development Tasks come in two forms:.

    Problems for developers to solve.
    Acts which simply need to be performed.
There is some good advice to found about how you should AssignProblemsNotTasks and if you're interested in problems head there.

Sounds a bit rude, it's not what is meant, it's good advice, seriously. Check it out. I for one couldn't agree more.

But Acts just don't get enough airplay I feel, so here it is, a rant in E minor as they say.

Reality.

Reality is that often developers need to perform simple acts like porting tables to divs, getting some exception handling around methods or changing a datatype in the database and then debugging all the code, procs and feeds that hook on to it.

Simple acts like putting a button on a screen that exports to PDF.

Simple acts like writing the method that powers the button.

We can dance around the topic and say that the problem is "the user can't export to PDF", but really, that's a UserStory, not a task.

A UserStory as in "As a user, I want to be able to export to PDF, so that I can conquer the universe".

The task in this case isn't a problem, it's the act of implementing a solution that is obvious to all.

The task is to sit down, shut up, tell your pairing partner to get another machine, start pasting and get typing.

And you know... this is rarely popular project management, but how else can I put it?

Let's pretend we're a rock band shall we?

Ok, we've written the songs, that was fun wasn't it?

Lots of creative juices flowing.

Lovely.

Now someone needs to play the bassline for 3 minutes while we make a recording.

Any volunteers?

DavidCasey

--------

also see: EngineeringTask