Let's say you've been tasked with an item of reasonably complexity in your ticketing system of choice. Whoever originally put together the item in the issue tracker was conscientious enough to make it a list of tasks, like so:
- Investigate best practice model for widget
- Build widget & test
- Configure integration with gromit.com
If that's the case, then you and the rest of your project team should feel confident with any one of you editing the description further, as tasks are done, and using either the <strike> HTML tag or "~~" in Markdown formatting, to strike them out as you complete them:
Investigate best practice model for widgetBuild widget & test- Configure integration with gromit.com
It seems like a pretty basic thing to do, but here are some advantages:
- You can see at a glance what work still needs to be done.
- The original text is still preserved: you can paste it with SHIFT-CTRL-v into a text editor and it loses the strikethrough formatting.
- Crossing tasks off a list, when you're justified in doing so, is an amazing psychological boost.
I've found this a hacky but tremendously satisfying way of both showing progress and feeling progress when tackling reasonably long features (but not so long that you'd split them out into many separate tickets), and I recommend it to you as a low-impact, low-tech way of taming requirements which are long and involved. And every strikethrough tag you use is like a little high-five you give to yourself as a treat for finishing the work.
More generally, I'm writing this about a humble HTML element because I love to see people being agile with their PM tools. Your PM tools need to work for you, and not the other way round; they need to flex and pivot to the ways in which you want to use them, and you need to feel comfortable with your team as a whole establishing conventions that might involve radically modifying documents, or document fragments. In traditional project management, these are considered to be somehow sacrosanct, set in stone; but a specification document can be dynamic (if people are happy with that) as long as the requirements themselves don't creep (by which I mean changing without project-wide agreement.)
With that in mind, of course, if your issue tracker doesn't let you edit descriptions after tickets are created (maybe with revision tracking for trust reasons) then you should get another issue tracker right away. As a stopgap, you could store your lists on something editable, like Google Docs, or a wiki. Also, I'd argue that only ad-hoc queries, speculative investigations and bug reports are exempt from needing to be massaged into a list of tasks; even then, the process of investigation of the query or bug should bring forth such a list. If clarity compels you to open another ticket to start such a list, do so gladly, and close the first ticket when you've got your list of tasks. Then strike, strike, strike through as you go.
Right, I'm going to go put together a list, of nothing in particular, and just strike through the items on it for the hell of it. Yeah!
