-
Notifications
You must be signed in to change notification settings - Fork 5
12. Tips and Best Practices
This page contains tips and best practices for using the PMT effectively.
Have you ever asked someone "Should I PMT you to do that?" Don't! The answer is always YES. Yes, put it in the PMT.
Action items and bugs in the PMT are cheap. Don't ever be shy about adding them. The worst that will happen is that someone will spend 5 seconds resolving the item as invalid or reassigning it to someone else.
The PMT remembers things so you don't have to. The PMT is like a free extension of your brain and a personal secretary all wrapped up in one. Once something is captured in the PMT, it can get reprioritized, reassigned, expanded, sorted and searched, tagged, and discussed. It might be deprioritized or explicitly closed, but it won't be silently forgotten about.
Don't send someone a task as an email or IM or voicemail or telegram. Put it in the PMT and let the PMT send the email. If everyone uses the PMT to assign tasks and report bugs, everyone can simplify their (work) lives knowing that everything that someone else expects them to do is captured in one central place.
A PMT Item should be a single atomic task, user story, or bug. The more granular the better (to a reasonable point).
When you're writing the description, pay attention to whether what you're describing is one thing or potentially several separate items. Are you describing multiple steps? or making a bullet list? Those should probably be separate items. Of course you'll have to use some discretion here. "Add the following user accounts: [list of users]" is a list, but is still basically one task.
In the early stages of a project, this can be a bit tricky since it might not be clear where the dividing lines on new features are. Relax and just put in what you know needs to be done. The PMT has the "split item" button for exactly this kind of thing. The priority is just getting everything into the PMT first, then you or another person can split the item up into sub tasks later once it's more clear.
Take a minute or two and make sure that your title and explanation are as clear and unambiguous as they can be. Write descriptions under the assumption that the item will some day be reassigned to a different person. That happens pretty frequently. Even if the item is never reassigned, it might take longer than expected for the assignee to get a chance to work on it. If they come back to it six months from now, will they still remember details that aren't in the description?
That means you shouldn't do something like "As we discussed in the meeting/chat/phone". A few minutes of writing now can save hours of repeating a complex explanation to a new assignee later, or going back and forth as it becomes clear that your understanding of the task was actually different than the assignee's.
A good approach here is to start by thinking about how you will verify the item later. Perform the thought experiment of "The assignee resolves this as FIXED. How will I actually verify that it truly was fixed?" Then make those expectations explicit and concrete.
Bugs are extra important to make clear. The classic issue with bug reports is "well, it works on my machine". Pretty much by definition, bugs are found in edge cases and less commonly seen nooks and crannies of the software. If you're reporting a bug, the developer probably doesn't stand a chance at fixing the bug if they can't reproduce it themselves. When you spot a bug, take some time to collect information about your specific setup and exactly what you were doing when you encountered it. Try a few different basic things to see first if you can reliably reproduce the bug yourself and which aspects of your setup might be contributing factors. Try reproducing the bug from a different web browser or on a different computer. A good bug report should have clear, minimal steps for reproducing the issue, a description of what you encountered, and sometimes a description of what the expected behavior should have been. Include information about what user account you were logged in as and roughly what time you encountered the issue (so developers can look through the system logs for anomalies).
Make things clear, and use complete sentences, but don't dress up your writing. Don't write PMTs like a formal letter. "Dear Bob, I hope you are doing well [...] best wishes, Anders".
Once an item is in the PMT and being discussed there, keep the discussion there. Don't take the conversation over to IM or email if you can help it. Sometimes synchronous conversation is useful to deal with a complex issue, but if you do take the conversation elsewhere, copy+paste or summarize back into the PMT.
Once again, operate under the assumption that the item will get reassigned to someone else who wasn't present for the beginning of the conversation. If it's all captured in the PMT, there's a nice paper trail of the decision making process and that's not a problem.
Similar to the last two points, you want a PMT item to be the single point that someone can go to get all they need to understand and potentially work on an item. If the item requires supporting information or resources (a spreadsheet of data, documents, etc, etc), attach them to the item or provide links to them directly from the item. Don't email them to the developer seperately or scatter them about the xserve and google drive.
In other words, if you want something done, make it easy for the person that has to do it. When you're creating the item, you probably have a good handle on where everything is; it's probably open right in front of you. Don't send the assignee on an information scavenger hunt.
There really is no good reason to let items linger in RESOLVED purgatory. If you own an item and it comes back to you resolved, make it a priority to either verify it or reopen it as appropriate. If it's done, great, verify it and let everyone have a little bit of closure and feel momentum on a project moving forward. If there's an issue, reopen it quickly so the assignee can deal with it while they still have the context of the item in their head. It sucks to make a tricky bugfix, resolve it, and then have it reopened after lingering for months and then have to start over again figuring out what was going on with that bug in the first place.
Make it part of your daily routine to go through your resolved items and deal with them. If you took the time to write the item with verification in mind as recommended above, it should only take a few minutes to verify an item.
Continuing that thought, you really should have a routine for using the PMT. I recommend at a minimum, loading your homepage once a day (probably in the morning), to see if there are items that can be quickly verified, checking if anything important is in there that you may have missed in your email, glancing at whether you've logged as many hours this week as you think you have, and then making a rough plan for the rest of the day based on the items that are in there.
Then, once a week (I recommend Friday afternoon), taking a few minutes to check your weekly report and fleshing out your hours and putting in status updates on any projects that had movement. Then go through each project that you manage and see if there are upcoming milestones that appear to be slipping and need attention.
We've emphasized the importance of just capturing everything in the PMT, whether you're sure it needs to be in there or not. The flip side of this is that everyone also needs to spend a little time tidying up as well to keep things in order.
Developers should take the time to triage bugs. Clear out duplicate bug reports. Resolve ones that aren't really bugs.
Project Managers should not let milestones pass with open items in them. When a milestone's approaching (or has just passed) and still has open items, take a moment to decide whether the milestone should be pushed back, or if the remaining open items in the milestone should either be cleared out or moved to another milestone.
The PMT's strength is the OPEN -> RESOLVED -> VERIFIED workflow between owner and assignee, but that doesn't mean that it's only useful for that kind of back and forth. Since the PMT works best when it's used for tracking all tasks on a project, it also supports simple "TODO list" type tasks. All the "TODO" items are is a regular action item where you are both the owner and assignee. There's a simple interface for adding large numbers of these small tasks quickly and easily. Once they're in the PMT, there's the potential that they could be reassigned (if you get busier than you originally thought you would be or it turns out that someone else is in a better position to handle it), hours are easy to log, and so on.
By far, the easiest way to log hours in the PMT is to just do it every time you resolve an item. If you resolve the item as soon as you're done working on it, you won't have to think very hard about how long you spent on it. The field for tracking time is right there in the resolve item form. If it takes more than a day or two to resolve an item and it starts to get hard to figure out how many hours you spent on it, that's a good clue that the item probably ought to have been split up into more granular tasks. If you are thinking "yes, but most of what I work on doesn't exist as PMT items", you probably need to get on board with TODOs and assigning things to yourself. As the week goes along, does the bar on your homepage stay green? Does it look like it's reflecting how much work you've actually been doing?
The longer you wait to track your time, the more painful it becomes and the less accurate you will probably be. So don't do that.
This is an important concept from KanBan that applies here as well. We all have limited attention and memory in our brains. The PMT tries to help you as much as possible by letting you dump information and get it back later in useful ways. But any work that is in progress or ongoing is attention and mental effort that you will have to exert for yourself. Try to keep it to a minimum. If you start something, try to finish it or get it to a stable state before you switch over to something else.
Keeping items granular (and splitting them up when they're not) helps with this.
Verifying items quickly helps with this (lingering RESOLVED items are essentially work in progress).
The "IN PROGRESS" and "RESOLVED" items both show up on your homepage in a very distinct manner to make it clear how much WIP you have so you can keep a handle on it.
Sometimes an item goes in, some discussion happens, and you realize that the item doesn't really describe what you want. There's a temptation to just edit the title and description and make it into something new. Don't do that. Just resolve it, make a new item and refer back to the existing one. The PMT doesn't keep a history of changes to title/description, so editing those destroys history. By all means, make small edits to fix typos and formatting or even add extra details to the description. But don't change an item into another item that way.