Jira apps for agile teams

Planning is a critical phase of the agile process; it's an opportunity to align on priorities as team and organize work in a sequence that will help it run smoothly. The planning process helps agile software development and other product development teams sort through new information, adapt to dependencies, and address evolving customer needs.

Agile is the opposite of traditional waterfall project planning, which takes a step-by-step approach. Waterfall has dominated project planning for many years, with detailed plans laid out at the beginning of a project that had to be adhered to rigidly. This may move a project or product forward, but it neglects to account for any new developments that could occur outside of the “master plan.”

Agile is an iterative process that helps teams reduce waste and maximize efficiency for the ultimate goal of bringing value to customers. This customer-first approach helps teams make informed choices throughout the development process — choices that continually and consistently provide value to stakeholders.

One of the greatest advantages of an iterative agile approach is that it enables early feedback from stakeholders. You don’t need to guess whether or not you’re making the right decisions — you can find out every step of the way by directly including stakeholders in your process. You can adapt your plan as you need to based on what will provide the most value to customers at any time.

Even if you are part of a seasoned agile team, there are always opportunities for improvement and processes to fine-tune. This post will outline some unproductive agile planning mistakes teams make, including how agile teams can avoid these common pitfalls.

Agile Planning Mistake #1: Not being on the same page as stakeholders

Do you involve stakeholders in your planning process? Do they understand your goals and why you are making each decision? Working directly with stakeholders, both internal stakeholders and the users of your product, will help you gain a clear view of both needs and constraints, and give you the information you need to determine what should be done when.

It's never a good idea to rest on assumptions. Your stakeholders live in a different world than the one you are deeply embedded in, with different priorities and assumptions of their own. So that you can produce deliverables that meet stakeholder expectations, you need to agree on what those expectations are. Involve your stakeholders in planning, but ensure everyone understands that expectations could evolve throughout the process based on new information gained from successes, failures, and customer responses.

Agile Planning Mistake #2: Not accounting for dependencies

Failing to account for dependencies in agile planning leads to bottlenecks, delayed releases, and undermines team collaboration. Collaboration within and across teams is needed for a business to deliver effectively. When multiple teams are working on interconnected features, if one team’s progress is blocked by another, the entire development cycle slows down. Without clear visibility of dependencies, work can be delayed and deadlines missed.

To minimize and avoid disruption to the flow of work, take the time to consult with stakeholders and anticipate dependencies early. Tools that help you visualise and map dependencies, and shared roadmaps to track cross-team dependencies, allow you to share an understanding of dependencies and sequence work in a way that avoids roadblocks. Proactively managing dependencies ensures smoother iterations, faster time-to-market, and a more predictable agile process.

Agile Planning Mistake #3: Using bland, flat product maps

Flat product backlogs are bland and boring 😴. Think carrot cake without icing. They lack the detail and functionality needed to realize the full story of your product backlog.

Plus, once you have more than a handful of items, they become overwhelming and difficult to organize in a meaningful way. It becomes less clear which item is the most important and more difficult to ensure your decisions align with the larger goal of the project.

When you plan out your roadmap, it needs context, and you must be able to clearly see the customer journey. User story maps visualize the customer journey in the planning process and throughout the entire process of product development. They utilize user stories — the smallest unit of work that can bring value to the customer — so you can plan and organize the backlog from the customer’s perspective.

📕 Read our ultimate guide to user story maps to learn more.

Agile Planning Mistake #4: Not allowing the plan to live, breathe, and adapt

As we've already discussed, agile is an iterative approach. This means your agile planning needs to leave room for changes. Your plan should be able to grow and adapt as you progress with each sprint or product roadmap.

At the beginning of a sprint, you lack the information needed to see the full picture. You don’t have everything you need to build the perfect solution, and that’s okay. It’s all part of the process. Spending hours or days trying to iron out the perfect plan just wastes time that could be better spent learning and solving problems as they come. What you thought would provide the most value during the planning phase could be completely different down the track.

You may need to alter your plan after a roadblock comes up in a daily stand-up, or you may learn about a customer concern that completely changes your direction. Iterations are inevitable and welcomed! They help you keep pace with incoming information as you learn from each other, stakeholders, and your customers.

Agile planning isn’t a promise. It’s an outline that will help you reach your goal, and that changes with your goals and circumstances.

Agile Planning Mistake #5: Not incorporating retrospective insights in the following planning session

Retrospectives are an essential piece of the agile process. They give teams a chance to reflect on everything that occurred in an individual sprint or after the completion of a product.

An effective retrospective asks the entire team key questions that can improve the process next time around. What went well? What’s worth repeating again? What didn’t go so well? What could be improved upon next time? What roadblocks or dependencies developed? What did you learn? How did you feel at the end of the sprint?

A retrospective provides insights that will improve efficiency, teamwork and team dynamics, the effectiveness of tools, and communication with stakeholders.

Simply holding a retrospective or collecting retrospective feedback is not enough to gain value. You need to ensure you’re incorporating the feedback into the following sprint planning meeting, and take action that leads to meaningful improvement. The next iteration will be all the better for the time you spend reflecting and improving based upon what you learned.

Agile Planning Mistake #6: Choosing tools that don’t take a customer-centric approach

Whether your team uses a Scrum process, kanban boards, or other agile methods, the tools you choose should always be customer-focused. And you need to continue using them in a way that keeps the customer at the forefront of decision making.

Teams can fall into a trap believing they’re focusing on the customer when they aren’t doing much of anything beyond following simple agile methods and generic processes. Customers need to be embedded in your development process right from the planning phase so that every decision a team member makes considers customer needs first.

Choose planning tools that help your entire team get to the heart of what makes your customers tick, and always check in to ensure you are making decisions in line with your customers.

For example, Personas provide a deep understanding of what customers want, need, don’t want, etc. They reveal key information about customer pain points, desires, demographics, goals, shopping patterns, and much more. We highly suggest developing customer Personas to get a rich picture of all the people who will use your product, but it’s not enough to just have Personas lying around.

You need to bring these Personas into your agile planning process and keep them front and center as you complete issues and continue to develop your product.

Scrum teams create release plans to support successful product releases. This helps them maintain their focus on the product vision and feature deliverables.

Here, we’ll explore agile release planning, why it’s important, and best practices to ensure successful releases.

What is agile release planning?

Because software projects are unpredictable, release planning helps team members prioritize their workflow. A release plan focuses on getting specific product features ready for the market. It should examine the product scope, the release date for feature completion, and the resources needed for each release.

The development team uses feedback from earlier product iterations to guide their planning. Product owners and Scrum teams meet to discuss the agile release plan, ensuring everyone understands the required product functionality and the effort needed for each increment.

Instead of planning for a significant product release, teams divide the project scope into short sprints. Many Scrum teams use Jira to help them visualize their sprints and track project status in real time.

Why is release planning important?

Agile release planning is critical for several reasons:

• Strategic alignment: It helps align development activities with broader business goals and customer expectations, so the highest-value features are delivered first
• Predictability: A clear release plan creates predictability, setting realistic expectations for stakeholders and improving overall project transparency
• Risk management: Identifying potential risks and dependencies early helps the team proactively address them, reducing the likelihood of significant delays or setbacks
• Improved collaboration: It promotes collaboration among team members and stakeholders, encouraging clear communication and a shared understanding of project goals
• Separation from product roadmaps: While a product roadmap provides a high-level strategy for the product, a release plan focuses on execution. Understanding this distinction helps teams use both tools effectively.

Project release planning helps software development teams plan, direct, and release each project in increments to serve the customer experience. Teams often use this methodology for short sprints of product development.

Release planning provides agile and Scrum teams with a solid direction to complete their projects. Team members also use this opportunity to use sprint feedback to create increments that align with the next release’s project roadmap.

Getting the product plan together

Release planning seems complex, but with some foresight, it can be simple. Let’s review each part of the process.

1. Who leads the release plan?

Typically, the product development team takes its lead from the Scrum master or the product owner. During the meeting, this leader will raise questions about the product backlog to ensure that sprint discussions align with the final product.

All the product stakeholders should participate in the release plan to ensure their feedback is taken into consideration. Without input from everyone involved in the product development, the team risks missing out on vital information to keep the product roadmap on track.

2. Agile release plan aspects

While the release plan is meant to be agile, it also follows a strict process to ensure that teams keep the product roadmap in sight.

Agile teams take all the sprint planning discussions and evaluate these to detail new product deliverables. Although most organizations will use various approaches in their release planning process, each sprint review should include the following aspects:

• The agreed product development releases at each stage of the sprint
• A direction for each new product release
• Specific current and future iterations due in each upcoming release
• What features and functionality should accompany the iteration
• Specific task requirements for each feature delivery to meet the release goal

By going through an in-depth release planning process, software development teams harness the value of these sprint meetings. The ability to rapidly change direction as necessary ensures the team releases the best possible product.

This constant iteration in each sprint review is also valuable in the dynamic environment of product development.

This level of planning, combined with an iterative schedule to account for the dynamic nature of software, is what makes Agile product development so valuable.

3. Sprint meeting discussions

Sprint meeting discussions revolve around user stories, product backlog, and product backlog items. Scrum release planning also considers other issues such as dependencies and product functionality. Other aspects that the team speaks about involve the next release and the number of sprints they must complete and deliver.

Essentially, team members must keep the product vision in mind for effective release planning. This vision helps team members isolate minimum market sprint feature batches and their release dates.

Sprint meeting discussions should include:

• Release plan prioritization of impending new product features and functionality
• Evaluation and inclusion of stakeholder feedback for each sprint
• Detailed descriptions of sprint deliverables and whether these fall into the category of product short-term increments or major longer-term releases
• Which product version will be ready for release and the ideal sequence of product releases to achieve each release goal

Development teams build several product versions. After creating these versions, they prioritize them to release the most important ones to users.

Part of the purpose of release planning is to ensure that all stakeholders are on the same product development page. Another element of these sprint planning meetings is to drive ownership and acceptance of the product vision.

Development of the release plan

There are four steps that software development teams follow to create their product plan.

1. Creating the vision

First, you need to define the vision for the product. Creating a clear vision produces a roadmap for the team to follow in each consecutive sprint. This vision should align with market demand and the product owner’s goals.

It also encourages team members to sift through which features they should prioritize. Similarly, the product roadmap helps teams evaluate the resources they need during the sprint review. Product planning also enables teams to be flexible. Planning reviews ensure direction changes to accommodate ongoing increments to achieve overall release goals.

2. Prioritization of the product backlog

After defining the vision, team members focus on prioritizing features in the product backlog. Here, stakeholder inputs must align with the vision to successfully implement user stories. User stories are vital to the process as they provide the background for detailing product features or functionality.

The product manager provides the team with direction at this stage to outline a viable release plan. This release plan must include the product release goals, release dates, and prioritization of user stories.

3. Set the Scrum planning meeting

The next step in the planning meeting is for the stakeholders to review the plan. Team members now have the chance to adjust deliverables in line with the vision.

Everyone must agree to the release plan at this stage before they can move forward to the next release.

Meeting agenda

Setting up a meeting agenda helps manage the release plan. The essential elements of the agenda for the Scrum framework include:

1. Product plan assessment

The Scrum team reviews the product roadmap to ensure that everyone accepts the product vision and goals.

2. Architecture evaluation

With each release, the Scrum team and product owner evaluate the previous sprint’s architecture. They examine the technical details of the product development and discuss any potential problems that can impact the product release.

Scrum teams go over the scope and estimates of their release plan. Team members determine whether their planning includes the risk of technical debt and if they can complete certain task aspects, such as documenting their work to meet deadlines. Stakeholders also review dependencies that can influence the product versions’ functionality.

3. Velocity and iteration assessment

Scrum teams go over previous iterations to review their velocity estimates. They align their estimates with the suggested iteration schedule to ensure they cover all vital elements.

The product manager controls this assessment to ensure points are assigned to user stories. Assessing user stories and assigning points demonstrate the level of effort the team must invest in each iteration. The total number of story points then represents the estimation of release dates for each sprint release.

An iteration schedule is built by the agile team to determine their velocity for the current and subsequent sprints during this assessment.

The team creates the release scope, which includes all the necessary releases. The Scrum master assigns work to each team member, and all the stakeholders agree to the plan before moving to the next step.

4. Agreement on the definition of done

The team members must now discuss what will qualify as the definition of done for each feature release. Team members must consider whether their evaluation of user stories meets all the product owner's acceptance criteria for release. Once they can prove the acceptance criteria are met in their assessment, they will know that a release completion is valid.

The definition of done must confirm that team members have completed all their assigned tasks for the user story. Team members must also record each task so that the product owner can assess their work.

5. Populate the product release schedule

The project manager can now populate and complete the release plan schedule. All stakeholders should be able to access the calendar to track progress. This release plan schedule helps everyone stay focused on product deliverables and release dates.

Best practices for agile release planning

To make your agile release planning effective, follow these key best practices:

• Set a clear product vision: Define a clear, shared vision that aligns with your customers’ needs and business goals. This helps guide your team's priorities and decision-making throughout the project.
• Prioritize features by customer value: Clearly identify and prioritize features that provide the greatest value to your customers and the organization. This helps your team stay focused on delivering impactful results.
• Regularly review and adapt your goals: Agile release plans aren’t set in stone. Regular check-ins ensure that goals remain relevant as priorities shift based on customer feedback, business needs, or market changes.
• Clarify roles and responsibilities: Make sure everyone on the team understands their role and what’s expected of them. Clear roles enhance accountability and help prevent misunderstandings or duplicated effort.
• Define a 'Definition of Done': Establish clear acceptance criteria for what constitutes a completed feature or release. This ensures technical and functional completeness before deployment.
• Integrate DevOps practices: Aligning agile release planning with DevOps methodologies enhances collaboration between development and operations teams, improving deployment frequency and reliability.
• Plan small, incremental releases: Break down large product releases into smaller increments. This approach lets your team deliver frequent updates, gather user feedback early, and adapt quickly to customer demands.

Get help with your release planning

Agile release planning is a vital part of the software development team’s success. Create a comprehensive agile release plan for minor or major releases, and you make your life simpler for an upcoming release. Focusing on the release plan calendar helps keep product owners and team members aware of the overall product vision.

At Easy Agile, we offer tools that support agile release planning directly within Jira. Easy Agile TeamRhythm supports collaborative release planning in Jira. The highly-visual story map format transforms the flat Jira backlog into a meaningful picture of work, making it easier to manage your backlog and plan your release.

Observability is a crucial aspect of building and maintaining reliable applications, and at Easy Agile, we've dedicated significant effort to making our applications as observable as possible. In a recent talk at Atlas Camp 2025, Ryan Brown, our Staff Engineer, shared our experiences transitioning to Forge and the lessons learned along the way. Here are the key highlights from his talk.

What is observability and why it matters

Observability is about gathering and visualizing enough data to understand the health of your software systems and fix problems when they arise. Unlike traditional monitoring, which tells you what happened and when, observability goes a step further to explain why and how issues occur.

For us at Easy Agile, strong observability has:

• Helped us make better decisions about performance and infrastructure needs
• Drastically improved our customer support by letting us quickly pinpoint issues
• Let us adapt to the reality of modern, distributed applications

As Ryan put it during his talk: "When I was working on applications back in the day, we were running on two, three, maybe four data centers at most. Now we're talking about applications that grow at a global scale with people using them across the globe."

Modern applications are far more distributed than they used to be, with thick frontends becoming as complex as backends. This distribution makes the traditional approach of manually checking a few servers inadequate - we need sophisticated observability solutions to understand what's happening across our systems.

The three pillars of observability

Observability stands on three key pillars:

Metrics

These are the number-based measurements of your software - CPU usage, request times, error counts, and so on. But raw numbers alone aren't very helpful. Context is critical - knowing you have five errors is very different from knowing you have five errors from one specific user on one server over two minutes.

Metrics become particularly powerful when identifying trends over time, so you can pinpoint when performance issues began or correlate changes with system behavior.

Logs

Logs are often the first thing engineers get experienced with when dealing with observability. They provide detailed records of events and are the cornerstone of understanding what's happening in your system. They give more information than metrics alone, capturing not just what happened but details about each event that occurred.

They're richer in information but also generate more data. For example, logs might tell you an error occurred because an API returned a bad response - but that alone still doesn't tell you why the downstream API failed.

Traces

Traces help you understand what's happening across all your systems working together. They track transactions as they flow through various services, showing you exactly what happens when a user clicks a button or performs an action.

"Tracing is surprisingly simple," Ryan explained. "You just have a unique identifier for a transaction that gets shared from one system to the next system to the next system."

Traces are particularly useful when you can expose that identifier to end users when something goes wrong. That ID can show you exactly what happened in that transaction, taking the guesswork out of troubleshooting.

‍

Observability on Connect vs. Forge

Our current Connect approach

At Easy Agile, we've implemented comprehensive observability across our Connect apps.

• Metrics, logs, and traces captured for all our applications
• All this data sent to a third-party observability service to get a centralized view
• Front-end components that also send observability data to the same service

The approach reduces cognitive load on our engineers and gives complete end-to-end visibility into user journeys and what's happening across our systems. For this Ryan recommends that you can use commercial services like Datadog or New Relic, or even open-source options like Signoz.

Transition concerns for Forge

When we first looked at Forge, we had several questions:

• How well would tracing work with Forge's communication model?
• Could we define our own custom metrics?
• Would we be able to collect metrics and logs from both front-end and back-end?
• Could we identify specific user transactions for support purposes?

At the time of our evaluation, Forge functions were the primary compute option available, which raised questions about how standard tracing libraries would work in Forge's unique communication model.

Experimenting with a simple app

Instead of trying to migrate one of our bigger products, we created a simple "Sprint Notes" app to test observability on Forge. This let us:

• Quickly iterate through different Forge topologies
• Keep the experiment focused on observability
• Include all the necessary components (UI, API, database)

We took this app through several stages:

1. Connect on Forge: Running our Connect app through Forge
2. Forge with Remotes: Using two approaches - calling remotes through Forge functions, and calling remotes directly from the UI‍
3. Forge Native: Completely rewriting the app to use Forge functions and entity store

Key findings

Connect on Forge

When running our Connect app through Forge:

• All our existing observability worked without modifications
• Front-end and back-end metrics continued to function as before
• Tracing identifiers propagated correctly
• Logs and metrics didn't appear in the Atlassian Developer Console (which makes sense since we weren't using Forge modules)

The observability story for Connect on Forge is pretty straightforward - it just works. As Ryan noted, "All the existing observability that we had in place on Connect worked just as it did before. There was no big change or issues with what we saw there."

We even experimented with different methods of sending data to our observability service, including using a proxy under our own domain, and everything worked consistently as long as the correct content security headers were set.

Forge with remotes

For Forge with remotes, we found:

• Front-end and back-end observability mostly worked
• We had to set permissions.external.fetch.client to allow sending metrics from the front-end
• Adding these permissions required a major version upgrade
• Metrics didn't capture all API calls, particularly front-end calls to Atlas APIs
• Tracing identifiers weren't exposed to remote callers, limiting end-to-end tracing

"This is a little disappointing... we found that when we did calls to our remotes, Forge would generate tracing identifiers for use on the back-end, but unfortunately those identifiers weren't then being exposed to what was making those remote calls," Ryan explained.

While we could see logs in the Developer Console and some metrics were captured, the inability to propagate tracing identifiers back to callers meant we couldn't achieve full UI-to-database traceability or show transaction IDs to end users without implementing workarounds.

Forge native

With a fully native Forge approach:

• Custom metrics and basic tracing are possible but require significant work
• We needed to implement custom handling with libraries like OpenTelemetry
• UI observability remained similar to the remotes implementation
• We could access correlation IDs through undocumented Forge API features

We managed to create a proof of concept showing traces from Forge functions to our observability service, though implementing complete data store tracing would require additional work.

Recommendations and best practices

Based on our findings, we recommend:

1. Establish observability baselines

Figure out what data you genuinely need instead of collecting everything. Observability services charge by volume, so collecting unnecessary data can quickly become expensive.

2. Use OpenTelemetry‍

It aligns with Forge's internal implementation and provides good standardization. While it may be harder to use than some out-of-the-box solutions, the long-term benefits are worth it.

‍3. Consider an observability proxy

This enables:

• Authentication for incoming metrics
• Adding additional context
• Data redaction for sensitive information
• Decoupling your implementation from specific providers

When combined with OpenTelemetry, this approach means your Forge components don't need to know what observability service you're using, avoiding permission changes if you switch providers.

4. Plan permission updates strategically

Since they require major version upgrades, incorporate them early in your development.

5. Other important considerations

• Major version upgrades are required when adding permissions for observability
• The documentation for exporting logs and metrics is technically correct but easy to misinterpret
• Traces do not automatically propagate back to callers in remote implementations

Final thoughts

Achieving all three pillars of observability on Forge is possible, though it requires different approaches depending on your implementation strategy:

• Connect on Forge works seamlessly with existing observability
• Forge with remotes requires some additional configuration
• Forge native needs more custom implementation

These experiments are being prepared for open source, so stay tuned to Ryan's LinkedIn for updates.