Jira Software is one such powerful platform that has revolutionized the way teams manage projects and tasks. However, with great power comes great responsibility. Users must harness the capabilities of Jira Software effectively to prevent it from becoming unwieldy, overwhelming, and hard to use. And it’s easier for this to happen than you might think. We have assisted numerous organizations in recovering from setbacks.
For this reason, we encourage you and your organization to take a lean approach when working in Jira.
Some people often confuse Lean and Agile concepts. They are indeed closely related and linked in many ways. While Agile may have overtaken the market in IT and Product organizations over the last decade or two, Lean focuses on reducing waste and maximizing value and flow. Agile and Lean go hand in hand and work marvelously together. Because let’s be real, the way you get faster is to cut anything that doesn’t add value to the customer.
Lean practices play a pivotal role in supporting agility within organizations by fostering efficiency, minimizing waste, and promoting continuous improvement. Lean principles, derived from Lean manufacturing, emphasize the importance of optimizing processes and eliminating non-value-added activities. By doing so, organizations become more agile in their operations. Lean practices encourage the reduction of unnecessary steps and delays, allowing for quicker response to customer needs and market changes. Lean also promotes a culture of problem-solving and waste reduction, which aligns closely with the Agile mindset of iterative progress and adaptability. In combination, Lean and Agile create a powerful synergy, as Lean focuses on streamlining processes, and Agile provides the flexibility to respond to evolving customer demands. This harmonious blend of principles supports organizations in their quest for enhanced productivity, customer satisfaction, and competitive advantage, all essential components of achieving agility in today's dynamic business landscape.
Let’s go back to a time when teams were using sticky notes for their Kanban boards, were co-located, and had standups right at the board itself. Those sticky notes aren’t large. You can only capture so much information on them, right? That was the point. Part of the reason frameworks like Scrum and Kanban and practices like sticky notes and user stories worked well is that they cut out a lot of the noise in the requirements and design documents. Teams had to include only the most important information because that’s all there was room for. It led to faster meetings, faster development, and ultimately a better mindset when it came to accepting iterative improvements or changes.
So let’s take User Stories as an example here. In Jira Software, we are provided a UI with many fields and ways to capture data. Data is helpful as it allows us to slice and parse the data and make better decisions. It also can make things more complicated and slow things down. There is a 32,762 character limit on the description, you can add attachments, add links, etc. Now, when we look at a sticky note, the original user story, and consider the 3 C’s of a user story it is much leaner. There is just enough information to get the gist. Does this introduce a risk that you may not have all of the information? Probably, the leaner approach can also help the team focus on only the most important aspects of that user story. Limiting the amount of data captured can help the team limit the amount of reading, meeting, and analysis they do so that they can focus on delivering something for the user to put their hands on and give feedback quickly. Our advice is to ensure you are not providing too much information in your stories. Provide enough to get started and remember in Agile we welcome change even late in development. We invite change and use it as a learning opportunity instead of seeing it in a negative light.
We find that many organizations will come back to us for help because their backlog in Jira has become unmanageable. There are no limits on how much data can exist within the backlog. How many times have you or a team member created another card only to find out it was a duplicate of one that already exists? Or maybe you can’t delete anything in your backlog because it will offend the person who requested it even if it will never get worked on. In this case, you are likely not being relentless with your priorities. Your backlog needs to be maintained and manageable. This is why I advise I have no more than 3 months of work in the backlog.
I’ve heard of some folks who get upset when their idea gets deleted or marked as “won’t do” in the backlog. This means it will oftentimes sit in the backlog for years so as not to offend anyone. Just sitting there with no intention to work on it at any point. This is a waste. It also leads me to believe that there are cultural challenges in the organization with being purposeful in the work we do. When we say NO to something we say YES to something of higher importance for the customers who keep coming back and keep the company relevant. When everything is a priority, nothing is a priority. If you find yourself with a never-ending backlog, set up a time to “clean out the attic” be conscious about what will be taken on in the next few months, and delete the things that won’t. Communicate (respectfully) that the item deleted was evaluated and won’t be worked on and therefore is being removed from the backlog. Keep it simple and keep it cleaned up so that your teams can focus on the important relevant and urgent work to be done and remove the noise.
Epics are another feature in Jira where I see users get overwhelmed with data. Similar to User Stories mentioned above, Jira allows for a lot of data and text to be captured. This can sometimes get in the way of being lean and defining the minimal viable product within a feature. There are many Product Owners and Product Managers I have coached in the past who want everything included in the Epic down to the tiny details. In the same sense as the User Story, this can become noise and distract from the focus of providing customer relief from some known business issue. When we can cut out the noise and focus on the most important aspects - especially the definition the MVP Teams can deliver faster and iterate as needed. Again, focus on the business value of the request over the minute details.
The Gantt chart - how much do I love thee. Yes, Ghannt charts can be really useful to understand the interdependencies between work, teams, solutions, etc. It can provide awareness of glaring scheduling issues. In Advanced Roadmaps, we can leverage scenario planning, and pull in various team and solution efforts to view various plans, it can be very insightful. It can also become a vacuum of information that no one looks at OR that some take for gospel as the definitive timeline on which items will be delivered. The problem is though, that this is just a scenario and many people we work with tend to think of this as gospel. Take Winston Churchill’s quote “Planning is essential, but a plan is useless”. The reason is that it is important to understand what the risks, assumptions, and dependencies are between the teams but we also understand that we will learn more as we go and the schedule will change.
Even very milestone-driven waterfall projects like construction have to take on change. People get sick, costs increase, and materials are no longer available or delayed. There is a reason that the Ghannt chart in AR4J has scenarios. It is so that you can map out different possibilities based on assumptions and have a better idea though not completely accurate of when the work will be delivered. Again, this is a best-case scenario. Also, note that in the tool there are practices and user knowledge needed to make sure you aren’t forgetting any of the items that should be in the plan. When working in person we can more clearly see everything on the board and quickly identify what might be missing because it is very easy to see what we have and what we don’t. That becomes less so within tools like AR4J. If a filter doesn’t take into account a specific rule or a team member makes a mistake and mislinks or misapplies a field you could be missing a chunk of work. Hopefully, the scope is small enough and your teams are up on their practices to ensure that this is quickly caught but it is a risk you need to look out for.
Sometimes, the more data you have the less important it becomes. I like big room planning events because it makes us focus on just that. When working in big room planning in person especially, we work with cards and boards that take up entire walls, and we can still only capture so much information. So what does this do as a forcing function? We focus on the gist and value proposition of the item and the important details. It makes us faster in the way we communicate and collaborate with other teams. In all honesty, I think this is a large part of the reason why online sprint planning and PI planning can feel so daunting. There is too much information and we’re all just squinting at a screen.
When we have too much information, it can distract us from the important bits. The human brain can only handle so many pieces of information at one time. Do yourself a favor and work with your teams to reduce the amount of data you hold on to. Clean out your backlog regularly and make sure you are capturing the most important information. So the next time you are writing up a user story or refining the backlog ask yourself if you have enough information to get started or if you need more data. Double-check you have the important pieces like LOE, Business Value, and priority identified. With those, your work will become much faster and easier to address. And another bonus is you’ll cut a lot of the noise that wasn’t necessary either.
I have been using Jira and Confluence for over a decade now. One of the reasons I came to Isos was to learn all the things I didn’t already know about the tools. The tools are extremely powerful. There is so much they are capable of and I am so happy to have the opportunity to work with individuals who know how to leverage the capabilities to build amazing solutions. That isn’t to say it is without its risks. With great power comes great responsibility. Remember that Jira and Confluence will NOT solve all of your problems. You and your teams will benefit greatly from implementing a lean-agile approach to keep your instances manageable and continuously deliver high value to your customers.
If you're interested in learning more about implementing a lean-agile approach contact us. Let us help you take your team to the next level!