Best practice JIRA management for your scrum team
As the Scrum Master for the After Digital team and within previous roles; as well as unblocking impediments, I sit between the development team and the production team, who, naturally, both have their own priorities. But, clear processes and great tools can alleviate much of this imbalance, improving productivity and efficiency.
Some of the woes I’ve heard over my years include:
“I am being chased for updates from the PM and have a lot of development to finish today.”
“I don’t know where he/she is with this bit of work so I need an update to give to the client.”
“I feel micro-managed on this project.”
“Can we find time before sprint review to see if we are meeting our sprint goal?”
“I’m concerned there isn’t enough time to complete this task and felt it was an unachievable deadline.”
All justified concerns and common in agency life. Apart from the fact that these issues are all communication-related, they have one thing in common; when we use JIRA properly, none of these issues exist... in my experience.
Albert Einstein sums up much of the essence of agile practice in this quote:
“Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning.”
Albert Einstein
As an agile business, our aim is to constantly iterate and improve. But, to do so we need to implement the tools that are most effective for the job. And, that’s why I love JIRA.
Maybe you don’t use JIRA and have another tool for tracking digital development work. That’s OK and the following still stands (even though I’m a devoted agilist, and agile and JIRA go together like beans on toast!). These tips will help you to get the most out of your tools and make sure you stay on top of your agile game:
Create good user stories (and lots of them) - e.g. Project managers (PMs) add stories and the development team break the tasks down to explain how they’ll build it:
User stories, and tasks associated with them; if done right, they can produce the best technical spec for your project. They can also identify gaps in your requirement gathering, which can become blockers to the entire story, rendering the story incomplete and relegated to the back of the backlog.
Good user stories and associated technical tasks allow for less scattered information and everything to be in the one place, that then leads to possibilities of other team members picking up tasks that were not originally intended/assigned to them, with the confidence that they have all the information needed to complete the task.
Always provide estimates - Always estimate anything going into a sprint and update the estimate as you work through the task as it’s ongoing. This helps the team to see how they’re tracking against the sprint goal. Remember, you always choose the estimate.
Use filtering to refine - JIRA facilitates many different ways of filtering so that users can create bespoke dashboards, and project views. This is particularly helpful when you are a team member of several projects and struggling with prioritising your workload. Get rid of the distractions, and filter by ‘your own issues’, or ‘blocker’, ‘critical’ and ‘high priority’/ ‘must fix’ for starters.
Use the comments section to update the ticket and other team members - Create a clear record trail, so that there is less need for constant updates for the PM. If JIRA tickets are regularly updated, contain relevant comments and make it clear where each task is, you shouldn’t need to have PM’s chasing for updates, as it’ll be clear how we’re tracking against our sprint goal.
Attach as much as you can for the developer/designer - the more info in a ticket the better. Reassign any with blockers to your PM and add a blocker flag, until you have what you need and can complete the task. In addition, raise poor ticket management with your Scrum Master - they are tasked with stopping this from continuing.
Make sure you have a clear definition of ‘done’.
This should be explained in your sprint goal within planning. The ‘definition of done’ (DoD) is a clear and concise list of requirements that a project output must adhere to for the team to call it complete. Whilst the DoD usually applies to all items in the backlog, ‘acceptance criteria’ relate to a specific user story. In order to complete the story, both the DoD and acceptance criteria must be met. Only then, do we move it into the ‘done’ category.
Establish a realistic sprint goal - You should always have a sprint goal when you begin sprint planning. The backlog grooming and tasks taken into the new sprint will essentially meet this sprint goal. This should provide a realistic view of what the team feel they can achieve in the sprint.
Move tickets as you prepare to start them (commit to it!) and keep them in line with progress. This lets PMs and your scrum master know how it’s tracking against the sprint goal, who has taken responsibility and keeps burndown and velocity reporting looking good.
If there is more than one team member in a team (which there always will be) anything in the ‘to do’ column should, and will, be seen as fair game to get stuck into. So, your intentions should be identified as soon as the decision has been made… not a couple of hours into it when another team member may have also started the same task.
Flag issues as soon as you have concerns about time, don’t wait until planning to raise a deadline, blocker or timescale issue. Your scrum master can deal with things far more effectively when they are flagged quickly and it will also minimise risk on the project. Few things will frustrate a scrum master more than flagging something you couldn’t do in the sprint review or sprint planning (*insert frowning emoji).
The development team should own the sprint! Your development team should lead the sprint planning session and have significant input to sprint goals and backlog grooming, based on how they’d like build to work effectively.
Commit to constant backlog grooming - Essential to tracking the overall project, the product owner and the rest of the team need to review items on the backlog to ensure the backlog contains the appropriate items, that they are prioritised and that the items at the top of the backlog are ready for delivery.
Create a physical and visible board - Have your board clearly visible to all and ideally up on the wall by printing off tickets, it makes it harder to avoid or forget the sprints tasks than if they were amongst many other browser tabs or online project boards.
Psychologically, the physical movement of tickets has been found to be far more rewarding and empowering to a development team than moving virtual tickets; it motivates and almost gamifies the race to sprint goals.
Use priority levels - The standard icons provided by JIRA are all quite similar, so either reduce the number of priority levels so that the most distinct are used and identified quickly and effectively, or JIRA does allow you to upload/import your own, so you can get creative.
Use an easily identifiable profile pic - It sounds silly, but when you have a crazy, busy backlog and multiple people on the project, tickets are much easier to find/move/amend when you recognise your team members in there. For example, here’s mine (I’m a geek, who loves Penguins... so, this is very fitting):
So, your intentions should be identified as soon as the decision has been made… not a couple of hours into it when another team member may have also started the same task.
Keep an eye out for duplication - This can be particularly problematic when clients have JIRA access. This can be avoided by having one point of contact for your client to enter bugs and the likes through JIRA. Your scrum master should also keep a keen eye on all JIRA activity, ensuring hygiene is maintained.
JIRA might not work for everyone, but it’s an essential tool here for us. If you wish to create a truly effective agile team, then you need to establish the tools and processes that work best for you - there is no one size fits all. But, I hope with the tips above you can enjoy being agile as much as we do, and increase productivity at the same time.
