I have worked on many teams over the years and I am certain if I asked a random person "Do you think our team could track our work better?" the majority of people would respond yes. I know this because on every team we had the "How can we improve our tickets?" conversation more than once. You typically don't have this conversation if everyone is happy with the status quo despite what agile would leave you to believe.
Putting aside that people tend to think things could be better, let's explore where to even begin.
You're setting out to change your work processes. Before you make changes, you should first understand why you are doing so. Usually it's in reaction to some pain points such as:
- I want to have a better understanding of what is going on right now
- I want to have a backlog of work
- I want the work to be prioritized
- We track our work but the project board is a mess and out of date
My recommendation here is to list out the reasons as a team because those reasons will help show you where you should focus your efforts. Then prioritize them. What is most important? What is least important? If the list is long, then you separate it into "Musts" and "Nice to haves". (I recommend limiting "Musts" to 3-5 items. Don't try to make too many changes at once. While at first the team is energized by the changes during the honeymoon phase, a bunch of new processes can become overwhelming leading to falling behind and the team feeling negative because "our board is in a bad state".) After you implement your changes, look at these questions a month later. Is the team doing better?
Once you have a handle on why you are changing, a good next step is to figure out what a discrete unit of work actually is.
Some call them tickets, some call them stories, and some call them issues. I am going to call them tickets for now but whatever terminology your team settles on, you should discuss what work you will track. It's easy to say "everything that people work on", but you need to examine it more closely. Here are common questions I have asked:
- Do I make a ticket for this task that is necessary to complete a feature?
- Everyone says yes to this
- What about improvement work such as rewriting a pipeline to work with more data sources?
- Some people say yes, others say "only do it while you're working on the pipeline related to a feature request. But then this leads to ticket estimate inflation to take into account these changes or improvement work never getting done.
- What about research? Someone goes "I want X" and your team doesn't even know how to solve this problem.
Someone needs to go investigate it and come up with a solution.
- Some people track this as research spikes, others don't.
- What about unplanned work? Say a team member gets paged on a bug, sets aside their work, and fixes the problem immediately. Do you add a ticket retroactively?
- Again, some teams track this and others don't. I do recommend tracking this because if your team is constantly doing unplanned work, expectations need to be set appropriately during planning.
- What about corporate trainings?
- I have never experienced people wanting to track these, but then, if you're using a tool to track what people are working on, why is this not included?
After you have determined when to even create a ticket, what goes inside a ticket? Here are some good conversation starters:
- What details go into a ticket?
- How much information is enough?
- Do you use subtasks to split up the work?
- Who is responsible for creating the ticket?
- Who is responsible for updating the ticket?
- Who is responsible for moving the ticket between states such as Backlog, To Do, In Progress, and Complete?
- Do you estimate the complexity of the work? If so, how?
- Do you have due dates? How do you determine these?
- Can a ticket be blocked?
- This sounds silly but if you talk to Scrum proponents, they will tell you a task can never be blocked (and Scrum software won't even let you mark a ticket as blocked!) because it should never have been put in the sprint in the first place. Which has "Scrum cannot fail it can only be failed" energy.
And now I will reveal the trap inside all these questions. People are idealists at their core. This is why they estimate projects will take less time than they actually do. Why they say "It's just a small change, how hard could it be?". And here, people will lean towards tracking an abundance of information because "More details means better tickets". But this comes at a cost.
Tracking a team's work is like being a cartographer in a world where the countries change every week. So the more you track, the more time you are taking from each team member. Ask yourselves "Do we want to spend 1 hour of each team member's day updating tickets?". Usually the answer is no. But if you ask people "Do you want more clearly written tickets that track due dates, estimates, subtasks, and spell out test cases?" a lot of people will say yes without taking into account the time investment.
As I mentioned before, the more detailed and more data you put in the ticket for tracking, the more burden you put on somebody to maintain these tickets. All of this has a cost. I have worked on some teams where the majority of a team member's time was maintaining the board state, updating tickets, splitting tickets, asking people if this ticket is necessary anymore. So either one person is in charge of keeping the board in good shape (the project manager approach), everyone shares responsibility maintaining the board (the communal approach), or no one has responsibility over the board (the way a lot of teams operate).
I say all this because I recommend teams always start with the least amount of information and add more data to tickets over time if the team determines it is necessary. I have worked on teams that mainly used just the title and priority fields because everyone on the team knew what the work was. (That's why we meet every morning for standup... right?) If a team member had a question about the ticket, they went and talked with people. Going the route of adding a bunch of processes and data points to each ticket and having elaborate descriptions right from the start can lead to burnout of whoever is maintaining the board.
You have two options: judge based on vibes or judge based on data.
By Vibes
How do people feel about the changes? Do team members feel that the changes have helped? This might sound silly but a lot of teams operate this way. Usually what kicks things off is a feeling that tickets could be better, not a data centric "I have wasted on average an hour per week tracking down information". And since people are notorious for misjudging the impact of changes, a vibes only approach will never give you a definitive answer on the effectiveness of your changes. But vibes are important! If someone says "I am having difficulty making ends meet", telling them "wages on average are higher than ever" is not going to win them over. The team needs to be able to voice problems they have and discuss them. Sometimes, though, the data can show a different picture.
By Data
Here's where project software sales comes knocking telling you that you're leaving productivity on the table by not using all the data and reports. So I will start this section off with a warning. Data alone will not tell you the complete picture. You get an automated notification that the team's velocity dropped over the previous month by 50%, are you panicking? Then, like a magician, I reveal most of the team was away for half of the month for holidays. The context teams operate in is missing from all the burn down charts, burn up charts, quarterly velocity metrics, etc.
My advice is to start small. You can track how many tickets are completed in a week/sprint/month/however long matters to your team. Track this for a few months and see if it's mostly stable. If not, why? Do tickets vary wildly in scope? Did you have a bunch of unplanned work injected? Just tracking ticket throughput can open up a lot of questions (which again is why you start with small changes. Change too much and suddenly you have too many new questions).
Some useful data to track (to reiterate, you don't need to track all of this starting out. Start small, and expand over time):
- How many tickets are completed each week/month
- How long does it take on average for a ticket to be picked up and completed? (Cycle time)
- How long on average from ticket creation to being completed? (Lead time)
- How are our estimates compared to actual time taken to complete?
- Backlog size over time (If your backlog continuously grows, it is likely to be full of no longer relevant tickets)
Here's the bad news. You are unlikely to have the power to make purchasing decisions for their organization. So let's look at the reality of several popular options that you might already be using.
Jira/Asana/Generic Project Management Software X
Honestly you can substitute any dedicated project management software here. These tools can be powerful, yet a lot of that power is wasted in my experience. Here are some requirements to use them effectively:
Get your admins to give you project level permissions
In enterprise environments, everything tends to be locked down to reduce risk. But sometimes this leads to teams being locked out of making changes to their project board. The generic project board IT gives you will never be satisfying. (It suffers from trying to make everyone happy so your ticket templates will have hundreds of fields and you won't be using workflows effectively). Having a team member with the ability to edit your own project settings is required in my experience. And if they refuse to give it to you, you can always keep requesting changes until they get the board in a better state for you or give you access to make their lives easier. (Some might find malicious compliance distasteful but there is minimal risk in being able to change the settings of your own board. If you're paying for project software, it has an audit trail)
Throw out the defaults, start simple, make it easy
Only add the fields you determined as a team. While it doesn't hurt to have due dates on ticket go unused, the less information displayed the more streamlined reading tickets becomes. Then add a template. If you have a unified language on tickets, pre fill the ticket out so whoever is creating the ticket has an easy time. You can even create multiple templates to make it easier, for instance:
- Bug reports
- Granting a user access to a system
- New features
- Research spikes
For instance, a bug report template might look like:
Bug report
Title: [Short sentence]
Description: [Several sentences]
How to Recreate:
- [Add each step here]
Artifacts:
- [Logs/Pictures/Video]
Automate what you can
These tools offer callbacks and plugins that can integrate with other tools. For example, you can have Jira move a ticket from In Progress to Completed when a Pull Request is merged in Github. Don't go crazy here with notifications (such as sending a message to the team channel every time a ticket is moved) because you will pollute your signal to noise ratio.
Github Projects
Github Projects has two things going for it:
- If you are already paying for Github Enterprise, it's included
- It's easy to link tickets with pull requests
That's it. Don't expect to get more than you would get out of Stickies on a Wall from a workflow perspective. I say this because it's surprisingly difficult to get any additional information out of Github. In my usage I have discovered there was no way to get the following information besides writing a project management program myself and pulling details from the Github API:
- Time it takes for tickets to be completed
- Time it takes from ticket creation to completion
- How our estimates compared to actual completion time
- Backlog size
I have seen teams give up on using Github Projects to evaluate team effectiveness and start tracking data in excel.
Excel/Google Sheets
Honestly, this is the option you take if you don't have any better options. It's more difficult to collaborate with and doesn't provide you much automation. This works best if you have a dedicated project manager responsible for the excel sheet in conjunction with a team focused ticket board (such as Trello). The team needs to be able to review the state of their effort and the project during the week. But the benefit is it's infinitely flexible due to its simplicity and is only limited by your time. Want to track new information? That can be either a new column, row, or sheet. But remember, each new tracked piece of information means more time you have to spend manually updating your excel sheet. So my advice is to stick to simple measurements like "Tickets completed in a sprint".
Sticky notes on a wall
In days of yore, before Jira, some teams would track their work by having a whiteboard on a wall and move sticky notes around. The sticky notes would contain just enough details to differentiate the work (i.e. a very short sentence like "Build pipeline" or "Migrate data") and maybe the names of who was working on it. Then they would move the ticket from Backlog -> In Progress -> Done as work was completed. And this was enough.
I am personally fond of this method because physically moving the ticket adds a physical sensation to completing work missing from simply clicking "Move to Complete column". I can look up and see the project state without opening a new browser tab and navigating to our tool. It also encourages reduced ticket sizes because, well, you can't fit too many details on a sticky note. The downside is it doesn't work in a remote setting and doesn't provide you any data unless you track it yourself (as noted in the excel section above).