When Your JIRA Standards are Too Low

Have you ever felt like your backlog on JIRA has turned into a hot mess? Missing descriptions, no components, or maybe some issues are a year old! If this is the case, your JIRA standards are too low and it is time to set some higher standards for you and your team. Routine backlog grooming can help with prioritization of issues but when there is list of junk on the backlog it can get overwhelming. JIRA is a simple issue-tracking, and project management tool. Enforcing data standards in JIRA will help in the long-run with reporting, and also saves time when you need to figure out what was completed, and the result of the work. Below, are few ideas for you to try today to clean-up your backlog and set higher standards.

Set Mandatory Fields
Set mandatory fields such as ‘component’ or ‘description’ and ‘Estimate’ fields so that the issue can be reviewed at a later time without any question as to what was completed and what the level of effort may be. It may seem obvious to put a description but some may feel a title filled with acronyms is enough. On top of that, I have also witnessed completed issues without an assignee, so anything is possible.
Remove Issues
It is okay to remove issues. If the issues are no longer needed, or even worse, they no longer make sense then it is time to remove it from the product backlog. If anything, the issues can be reopened. However, keeping a long-list of unwanted features, or bug tracking tools, can make it appear as if there is more work to do than necessary.
QA regularly
Set some time each week to review items on the backlog. This is a work-in-progress, so it may not be perfect right away. Is there a description? Does it make sense? Is there acceptance criteria, or a definition of done?
Clear Purpose
Ensure that your team understands the purpose of JIRA. If you have multiple teams or projects, I recommend having the team leads reinforce these standards. With multiple teams or projects, it may become difficult to manage if the purpose is not defined from the beginning.

Above are just a few steps to cleaning up your backlog on JIRA and setting some standards. It is not too late to start developing new standards for your team moving forward.

Good luck.

Implementing Agile: First Things First

I looked online to find blogs, advice, and tips on how to implement Agile onto an existing technical project. I found a lot of comparisons, arguments on why Agile is great, and why it isn’t. However, the point of being Agile isn’t to memorize facts to win the next waterfall vs. agile debate. The point of being Agile is to practice it daily, and to get better at it everyday. Somewhere along the line, a leader in your organization agreed to making an Agile transformation and this is your chance to make a change.

The best advice I can give a program manager who wants an Agile transformation for their program, or to anyone tasked with implementing Agile is to live, breath and think Agile. Remember that you are setting the standards for software delivery. So, try not to take the title lightly. People will follow your lead. Next, find some books related to agile, organizational change, and leadership. Also, find a great podcast to listen to in the morning before heading to work. What helped me, was learning that there are people out there who are passionate about agile and it inspired me to learn more and do my best. Another tip is to find a group of people who are also passionate about Agile. This can be at your company, or find one on meetup. If you can’t find one, perhaps start your own.

So, if transforming your organization with Agile is now your task, then definitely be all about it and set the standard. Passion goes a long way and your efforts will be appreciated!

Podcasts to Try:

When you’ve been tasked to “do scrum”

Red flags were all over when she said,”do scrum” and “fit the schedule into sprints”. Being an IC Agile Professional, I know you don’t just “do scrum”. I was speechless but the speechless system design engineer in me, and now suddenly the new scrum master of the team, had bills to pay. So scrum master it is. So, I decided to start “doing Scrum”. Implementing Agile across a program has been my most challenging, stressful job I have had yet, and I can’t say it has been rewarding. Most people on my team have been doing things their way, doing the SAME thing they have always done for longer than I have been alive. So, being the chosen one to introduce a new way of doing this was not the best work-scenario.

My first scrum ceremony was a fail. No one showed up. Fast forward 6 months, it’s getting better but still the same resistors. I tried a user story writing session. I thought it was going to be a fun-filled session with sticky notes – ended in crickets. The engineers had no idea who the user was, or what a feature is, they only understood architecture. It was baffling to me. Something so easy (writing user stories) was so difficult.

Honestly, the role is undervalued. I feel like it is me against 30+ people, plus I am leading a major change without any authority. Conflicting requests from leadership has been my greatest difficulty. They want agile but also not displaying much support for it. However, I have some learning lessons.

Before going all crazy with the scrum ceremonies, come up with a plan of what you will introduce and when. Create a presentation of what scrum is and what scrum is not and present that to leadership. Leadership needs to be onboard and fully understand the roles before attempting to change anything. That way you have their authority early.
Start tracking success. Come up with some goals and how you will get there. It could be participation, stakeholder engagement, process improvement etc. This will take some research.
Lastly, JOIN SOME AGILE GROUPS. Seriously, you will feel alone sometimes because 9 times out of 10 you will be when someone asks you to do scrum. I found some great podcasts, blogs, and reached out to agile coaches within my organization. By doing so, I found out I wasn’t alone and most of the issues I was facing were normal. I also found out, that people LOVE it, they LOVE talking about SCRUM. Seeing the passion for it motivated me to try harder.

At the end of the day, I am doing this on top of my system design engineering duties and it is not fun. I’m not going to lie. I think if I was back in management consulting where we take a formal approach to change management and business process improvement, it would be much more rewarding. However, casually “doing scrum” is not the way to go.