Wednesday, August 5, 2015

Task Management (vs) Transparency



Start by writing ambiguous tickets on large umbrella tasks based on the things you *know* that must be accomplished, no matter how the work is sliced. This is usually encouraged by management professionals who try to use these tracking tickets to watch your progress.

Additionally, you write tickets as you go, on an as-needed basis.

When you do write tickets, add a title summary and a point score. You don't know what goes in the description yet because -- even though you know what must be accomplished -- you're not sure how to describe the task yet. Figuring this out is often a matter of actually doing the task. Now you have an important ticket, but its also mostly tacit. 


As you run into errors and other issues or blockers in the progress of the ticket, add them in the comments. As issues get resolved, add those in the comments as well. Add links to related information.


Figure out how to describe your task in a set of executable steps.

Add a statement explaining the [expected] result from doing this task. 

Lots of content gets removed from a ticket as it gets sized to fit its point score, over the course of a sprint. Shaving off some component of the task and re-categorizing it and putting it in the backlog is sometimes the only way to wrap a sprint up in the headlights of a rushing deadline. (That *does* get into dangerous territory under conditions of fatigue and motivational depletion.)


A ticket may be extremely important during a sprint, but can potentially stay mute for a considerable period before its subject to this adding-and-removing of content. When this ticket comes up in search results, for anyone who is looking at your project, it's interstitial to the large ambiguous module-level tracking tickets that roll from one sprint to the next, originally created for management purposes.  

Your ticket scene may appear to be a wasteland of tasks that never get done.

When your managers have their eyes on the ball and write you a ticket that falls squarely in your domain, this event can occur before *you're* aware of the [importance of the] demand. So when you *become* aware of it: write a ticket.

Now you have duplication: multiple tickets requesting the same thing.   

Pull up all your recent tickets on a project, and realize that multiple ones have the same exact title summary. How did THAT happened?


When a task is complete and its time to close a ticket, close it. Sometimes you'll add information to comments to resolve any lingering questions, but most importantly, add a comment justifying why its being closed. The rest of the content will most likely be frozen in the state that it's in at the time of close.


Weeks and sprints and months go by. What you have accumulating is a forest of tickets to your name that are stale and stagnant, or closed and inarticulate. Other engineers can't navigate through it to get an idea of what you're doing, and you're so busy coding away at the task at hand that you fail to *see the forest from the trees*. Your project may be thriving, but without representing this progress in tickets and other public records... lets just say that only YOU can prevent your own forest fires.  




3 comments :

  1. Isimply want to tell you that I am new to weblog and definitely liked this blog site. Very likely I’m going to bookmark your blog . online timesheets

    ReplyDelete
    Replies
    1. I'm very sorry for the delayed response, thank you greatly for your feedback. This is wonderful, please feel free to further this discussion, provide any suggestions, and/or tell me how you found this article.

      Delete
    2. Wow, i just realized my response wasn't very delayed. haha

      Delete