Junk and not so junk tasks

clip_image002One of the dev teams in my company used in their job so called junk tasks (well, they actually called them “doo-doo tasks” (the first picture was used to represent the tasks), but let it be junks 😉 ). They were such small tasks one could do quickly. What is the result of a task quickly done? Right: increased happiness and motivation. Well, the task is done quickly too. The tasks queue was filled by a team lead, who regulated quantity of the junks in it, basing on some set of rules, from which we are now interested in one particular:

clip_image004

That is we have to limit such tasks. То есть количество таких задач должно быть ограничено. Moreover, developers have various stuff like agile and other waterfalls, which with the help of sprints help restrict tasks per minute. So, like it or not, you’ll have to do all of them. As a result you maintain focus, because the queue is finite (this itself is very important) and motivation doesn’t drop just because you don’t have a choice what to do right now.

Overall, in the world of developers there is if not happiness, then at least appearance of it. And what do we have in the world of IT Pro (system administrators and so on)? It’s easier to say what we don’t have:

1) There is no spoon SCRUM for sysadmins

2) There is an opinion that the task which can be done in 30 minutes NET time shouldn’t be done in 2 weeks. The only ground for the thought is “well… it is only half an hour, after all!!!”

3) The chart showing for how long your tasks are in your backlog looks as following:

clip_image006

Easy to understand that some tasks have no chance to be completed at all. BTW, a short quiz: what are the best candidates for this? 😉

As a result, while hard and not interesting tasks get themselves into “more than month” category, quantity of such small and pleasant tasks potentially infinite. And sure as hell, some of the projects are way behind the schedule.

Are there any ways to save chance to pick up a small and easy task between hard ones without postponing the latter forever? Here is what I found out yet:

1) To put some restriction on tasks. Alternatives:

a. Rely on the worker ability to follow this path.

b. Real restriction: quantity of small tasks not more than X% from the overall quantity.

c. Another real restriction: we accept only some amount of tasks. As for other tasks… Come to us in a week =)

2) Don’t get it into your head. After all, tasks are being done, reports are written. As for the not-done-in-time projects… Well, look how much work we have: we just don’t have enough resources.

3) Do everything in the order it came into your backlog (FIFO, if you know what I mean). Don’t allow priority change in some time window (say, a week) no matter what. Of course, we don’t speak about incidents.

4) Consider some types of tasks of more priority than others. That is if we have such a task in the backlog, we don’t do others. It’s actually a variation of 1b, but with floating percentage.

I believe I haven’t found all the variants. Do you have any?

Later we’ll speak about pros and cons of the above.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s