Easy Agile Team

Observability ist ein entscheidender Aspekt bei der Entwicklung und Wartung zuverlässiger Anwendungen, und bei Easy Agile haben wir große Anstrengungen unternommen, um unsere Anwendungen so beobachtbar wie möglich zu machen. In einem kürzlichen Vortrag auf dem Atlas Camp 2025 berichtete Ryan Brown, unser Staff Engineer, über unsere Erfahrungen bei der Umstellung auf Forge und die dabei gewonnenen Erkenntnisse. Hier sind die wichtigsten Höhepunkte seines Vortrags.

Was ist Beobachtbarkeit und warum ist sie wichtig

Bei Observability geht es darum, genügend Daten zu sammeln und zu visualisieren, um den Zustand Ihrer Softwaresysteme zu verstehen und Probleme zu beheben, wenn sie auftreten. Im Gegensatz zur herkömmlichen Überwachung, bei der Sie erfahren, was wann passiert ist, geht Observability noch einen Schritt weiter und erklärt, warum und wie Probleme auftreten.

Für uns bei Easy Agile bedeutet starke Beobachtbarkeit:

• Hat uns geholfen, bessere Entscheidungen über Leistungs- und Infrastrukturanforderungen zu treffen
• Wir haben unseren Kundensupport drastisch verbessert, indem wir Probleme schnell lokalisieren konnten
• Passen wir uns an die Realität moderner, verteilter Anwendungen an

Ryan drückte es in seinem Vortrag so aus: „Als ich damals an Anwendungen gearbeitet habe, liefen wir auf zwei, drei, vielleicht höchstens vier Rechenzentren. Jetzt sprechen wir über Anwendungen, die auf globaler Ebene wachsen und von Menschen auf der ganzen Welt genutzt werden.“

Moderne Anwendungen sind weitaus verteilter als früher, und dicke Frontends werden so komplex wie Backends. Aufgrund dieser Verteilung ist der herkömmliche Ansatz, einige Server manuell zu überprüfen, unzureichend — wir benötigen ausgeklügelte Observability-Lösungen, um zu verstehen, was auf unseren Systemen vor sich geht.

Die drei Säulen der Beobachtbarkeit

Observability basiert auf drei Hauptpfeilern:

Metriken

Dies sind die zahlenbasierten Messungen Ihrer Software — CPU-Auslastung, Anforderungszeiten, Fehleranzahl usw. Aber rohe Zahlen allein sind nicht sehr hilfreich. Der Kontext ist entscheidend — zu wissen, dass Sie fünf Fehler haben, ist etwas ganz anderes als zu wissen, dass Sie innerhalb von zwei Minuten fünf Fehler von einem bestimmten Benutzer auf einem Server haben.

Metriken sind besonders aussagekräftig, wenn es darum geht, Trends im Laufe der Zeit zu identifizieren, sodass Sie genau feststellen können, wann Leistungsprobleme auftraten, oder Änderungen mit dem Systemverhalten korrelieren können.

Logs

Logs sind oft das Erste, womit Ingenieure Erfahrung sammeln, wenn es um Observability geht. Sie bieten detaillierte Aufzeichnungen von Ereignissen und sind der Eckpfeiler, um zu verstehen, was in Ihrem System vor sich geht. Sie liefern mehr Informationen als nur Metriken und erfassen nicht nur, was passiert ist, sondern auch Details zu jedem Ereignis, das eingetreten ist.

Sie sind reicher an Informationen, generieren aber auch mehr Daten. Logs könnten Ihnen beispielsweise sagen, dass ein Fehler aufgetreten ist, weil eine API eine schlechte Antwort zurückgegeben hat — aber das allein sagt Ihnen immer noch nicht, warum die Downstream-API ausgefallen ist.

Spuren

Mithilfe von Traces können Sie nachvollziehen, was auf all Ihren Systemen passiert, die zusammenarbeiten. Sie verfolgen Transaktionen, während sie verschiedene Dienste durchlaufen, und zeigen Ihnen genau, was passiert, wenn ein Benutzer auf eine Schaltfläche klickt oder eine Aktion ausführt.

„Die Rückverfolgung ist überraschend einfach“, erklärte Ryan. „Sie haben lediglich eine eindeutige Kennung für eine Transaktion, die von einem System zum nächsten System gemeinsam genutzt wird.“

Traces sind besonders nützlich, wenn Sie diese Kennung Endbenutzern zur Verfügung stellen können, wenn etwas schief geht. Diese ID kann Ihnen genau zeigen, was bei dieser Transaktion passiert ist, sodass das Rätselraten bei der Fehlerbehebung ein Kinderspiel ist.

‍

Beobachtbarkeit bei Connect und Forge

Unser aktueller Connect-Ansatz

Bei Easy Agile haben wir umfassende Observability für unsere Connect-Apps implementiert.

• Für alle unsere Anwendungen erfasste Metriken, Logs und Traces
• All diese Daten werden an einen Observability-Dienst eines Drittanbieters gesendet, um eine zentrale Ansicht zu erhalten
• Frontend-Komponenten, die auch Observability-Daten an denselben Dienst senden

Dieser Ansatz reduziert die kognitive Belastung unserer Techniker und bietet einen vollständigen Überblick über die Benutzerabläufe und das, was in unseren Systemen passiert. Dafür empfiehlt Ryan, kommerzielle Dienste wie Datadog oder New Relic oder sogar Open-Source-Optionen wie Signoz zu verwenden.

Bedenken hinsichtlich des Übergangs für Forge

Als wir uns Forge zum ersten Mal ansahen, hatten wir mehrere Fragen:

• Wie gut würde Tracing mit dem Kommunikationsmodell von Forge funktionieren?
• Könnten wir unsere eigenen benutzerdefinierten Metriken definieren?
• Wären wir in der Lage, Metriken und Logs sowohl vom Frontend als auch vom Backend zu sammeln?
• Könnten wir bestimmte Benutzertransaktionen zu Supportzwecken identifizieren?

Zum Zeitpunkt unserer Evaluierung waren Forge-Funktionen die primäre verfügbare Rechenoption, was Fragen zur Funktionsweise von Standard-Tracing-Bibliotheken im einzigartigen Kommunikationsmodell von Forge aufwarf.

Experimentieren mit einer einfachen App

Anstatt zu versuchen, eines unserer größeren Produkte zu migrieren, haben wir eine einfache „Sprint Notes“ -App erstellt, um die Beobachtbarkeit auf Forge zu testen. Dadurch konnten wir:

• Iterieren Sie schnell durch verschiedene Forge-Topologien
• Konzentrieren Sie sich beim Experiment auf die Beobachtbarkeit
• Beinhaltet alle notwendigen Komponenten (UI, API, Datenbank)

Wir haben diese App durch mehrere Phasen geführt:

1. Verbinde dich auf Forge: Unsere Connect-App über Forge ausführen
2. Forge mit Fernbedienungen: Verwenden Sie zwei Ansätze: Aufrufen von Fernbedienungen über Forge-Funktionen und Aufrufen von Fernbedienungen direkt von der Benutzeroberfläche aus‍
3. Forge Native: Die App komplett neu schreiben, um die Forge-Funktionen und den Entitätsspeicher zu verwenden

Wichtigste Ergebnisse

Auf Forge verbinden

Wenn Sie unsere Connect-App über Forge ausführen:

• Unsere gesamte bestehende Beobachtbarkeit funktionierte ohne Änderungen
• Frontend- und Backend-Metriken funktionierten weiterhin wie zuvor
• Die Ablaufverfolgungskennungen wurden korrekt weitergegeben
• Logs und Metriken wurden nicht in der Atlassian Developer Console angezeigt (was sinnvoll ist, da wir keine Forge-Module verwendet haben)

Die Observability-Story für Connect on Forge ist ziemlich einfach — sie funktioniert einfach. Ryan merkte an: „Die gesamte Observability, die wir auf Connect eingerichtet hatten, funktionierte genauso wie zuvor. Es gab keine großen Änderungen oder Probleme mit dem, was wir dort gesehen haben.“

Wir haben sogar mit verschiedenen Methoden experimentiert, um Daten an unseren Observability-Dienst zu senden, einschließlich der Verwendung eines Proxys unter unserer eigenen Domain, und alles funktionierte konsistent, solange die richtigen Content-Security-Header gesetzt waren.

Forge mit Fernbedienungen

Für Forge mit Fernbedienungen haben wir Folgendes gefunden:

• Frontend- und Backend-Observability funktionierten größtenteils
• Wir mussten permissions.external.fetch.client so einstellen, dass Metriken vom Frontend aus gesendet werden können
• Das Hinzufügen dieser Berechtigungen erforderte ein Upgrade der Hauptversion
• Metriken erfassten nicht alle API-Aufrufe, insbesondere Frontend-Aufrufe an Atlas-APIs
• Tracing-Identifikatoren waren Remote-Anrufern nicht zugänglich, wodurch die durchgängige Verfolgung eingeschränkt wurde

„Das ist ein bisschen enttäuschend... wir haben festgestellt, dass Forge bei Anrufen an unsere Fernbedienungen Tracing-Identifikatoren für die Verwendung im Backend generierte, aber leider waren diese Identifikatoren dann nicht dem ausgesetzt, was diese Fernanrufe tätigte“, erklärte Ryan.

Wir konnten zwar Protokolle in der Developer Console sehen und einige Metriken wurden erfasst, aber die Unfähigkeit, Tracing-Identifikatoren an Aufrufer weiterzuleiten, bedeutete, dass wir keine vollständige Rückverfolgbarkeit von der Benutzeroberfläche zur Datenbank erreichen oder Transaktions-IDs den Endbenutzern anzeigen konnten, ohne Problemumgehungen zu implementieren.

Forge-Einheimischer

Mit einem vollständig nativen Forge-Ansatz:

• Benutzerdefinierte Metriken und einfaches Tracing sind möglich, erfordern jedoch einen erheblichen Aufwand.
• Wir mussten eine benutzerdefinierte Handhabung mit Bibliotheken wie OpenTelemetry implementieren
• Die Beobachtbarkeit der Benutzeroberfläche blieb ähnlich wie bei der Remote-Implementierung.
• Wir könnten über undokumentierte Forge-API-Funktionen auf Korrelations-IDs zugreifen

Wir haben es geschafft, einen Machbarkeitsnachweis zu erstellen, der Spuren von Forge-Funktionen zu unserem Observability-Dienst zeigt, obwohl die Implementierung einer vollständigen Datenspeicherverfolgung zusätzliche Arbeit erfordern würde.

Empfehlungen und bewährte Verfahren

Basierend auf unseren Ergebnissen empfehlen wir:

1. Legen Sie Basiswerte für die Beobachtbarkeit fest

Finden Sie heraus, welche Daten Sie wirklich benötigen, anstatt alles zu sammeln. Observability-Dienste werden nach Volumen abgerechnet, sodass das Sammeln unnötiger Daten schnell teuer werden kann.

2. Verwenden Sie OpenTelemetry‍

Es entspricht der internen Implementierung von Forge und bietet eine gute Standardisierung. Es ist zwar schwieriger zu verwenden als einige sofort einsatzbereite Lösungen, aber die langfristigen Vorteile sind es wert.

‍3. Ziehen Sie einen Observability-Proxy in Betracht

Dies ermöglicht:

• Authentifizierung für eingehende Metriken
• Zusätzlichen Kontext hinzufügen
• Datenredigierung für sensible Informationen
• Entkopplung Ihrer Implementierung von bestimmten Anbietern

In Kombination mit OpenTelemetry bedeutet dieser Ansatz, dass Ihre Forge-Komponenten nicht wissen müssen, welchen Observability-Dienst Sie verwenden, wodurch Berechtigungsänderungen vermieden werden, wenn Sie den Anbieter wechseln.

4. Plane Genehmigungsaktualisierungen strategisch

Da sie wichtige Versionsupgrades erfordern, sollten Sie sie frühzeitig in Ihre Entwicklung einbeziehen.

5. Weitere wichtige Überlegungen

• Größere Versionsupgrades sind erforderlich, wenn Berechtigungen für Observability hinzugefügt werden
• Die Dokumentation für den Export von Logs und Metriken ist technisch korrekt, kann aber leicht falsch interpretiert werden
• Traces werden in Remote-Implementierungen nicht automatisch an Aufrufer weitergegeben

Abschließende Gedanken

Das Erreichen aller drei Säulen der Beobachtbarkeit auf Forge ist möglich, erfordert jedoch je nach Ihrer Implementierungsstrategie unterschiedliche Ansätze:

• Connect on Forge funktioniert nahtlos mit vorhandener Observability
• Forge mit Fernbedienungen erfordert eine zusätzliche Konfiguration
• Forge Native benötigt mehr benutzerdefinierte Implementierung

Diese Experimente werden für Open Source vorbereitet, also bleiben Sie dran Ryans LinkedIn für Updates.

"Bottleneck" is a buzzword you don't want to hear. When it comes to your production process, maximizing your time and budget is all about keeping efficiency high. However, simply cutting the steps in your process may not make your customer any happier. If you want to achieve a high return on investment and increased customer satisfaction, value stream mapping is an ideal way to keep your team on track.

What is value stream mapping?

Value stream mapping (VSM) is a technique from the lean principles methodology that helps you visualize the steps you need to take to deliver a finished product or service. Value stream maps outline the flow of information and the physical materials to see where value is added for the customer. The purpose of VSM is to increase efficiency by reducing waste in the production process.

Widely known as the lean manufacturing method used in the Toyota Production System, VSM is now often used to eliminate bottlenecks in other industries like software development, supply chain, and healthcare. It's a versatile technique that can help many organizations shine. 🌟

Streamline visibility and provide transparency of your Program for all teams

Easy Agile Programs

Join a demo

Why value stream mapping matters

When companies aim for efficiency, they often focus on reducing the total amount of production steps required. But customers don't always see what happens behind the scenes. Decreasing the length of your workflows mainly benefits your process without changing the experience for them. On the flip side, the value stream mapping process keeps your team members aware of customer needs, so your business can stand out.

For teams that use value stream mapping, reducing inefficiencies is all about cutting production process steps that don't add value. Value stream maps are a visualization of where you're wasting effort. They show your team that keeping steps within your process is okay — but each of those steps should help customers in some way. As a result, VSM prevents overproduction while ensuring your customers are happy with your final product or service.

You can achieve better lean agile workflows with value stream mapping and effectively keep up with customer demand. 💪

Value stream mapping terms

A typical value stream map is divided into three key sections — information flow, material flow, and lead time ladder — that help you see where process improvements can occur. To help you complete each part of a value stream map with greater ease, we'll explain a handful of common terms that you'll come across in each section.

As you learn these terms, you can refer to this Microsoft template to see a few VSM symbols that you'll often use.

Information flow

At the top of a standard value stream map is an information flow section that shows how data transmits between your team members, customers, and other stakeholders. Common terms you'll need to know to complete this section include:

• Customer: This is the consumer who will receive your final product. Your customer is represented in the upper right corner of your map.
• Supplier: This is your organization. Suppliers are placed in the upper left side of value stream maps.
• Dedicated process flow: This is a process or department (like "production control") that information flows through.

Material flow

In the middle of a value stream map is a material flow section that shows how you take your product or service to delivery, step by step. Each box represents a unique task, which may be performed by the same team or by another after a material handoff.

To complete the material flow section, you need to know these terms:

• Shipments: On value stream maps, "shipment" arrows point from the supplier to the first step in the material flow, or from the last step to the customer. They show how your information flow is related to the start and end of your production process. For example, an arrow can show how raw materials move between the supplier and factory or how software access is "sent" to a user.
• Cycle time (C/T): This metric represents the amount of time required between shipments.
• Inventory: Inventory is what's produced between each stage of the production process. Your inventory is usually written below a triangle with a "I" within it. 🔺

Lead time ladder

At the bottom of a value stream map is usually a time ladder that helps you visualize your lead time, which is the average time spent on each step of your material flow.

Kaizen burst

Throughout your value stream map, you can include Kaizen bursts. These represent bursts of activity (like a sprint) in which your team focuses on resolving a specific issue — such as processing customer returns — to quickly remove potential bottlenecks. The symbols for Kaizen bursts look like comic book explosions to grab your attention. 💥

How to create a value stream map

When you're ready to get started with value stream mapping, select the specific product or service that you want to create a map for. While all production processes can benefit from continuous improvement, you should ideally start with a product or service that could benefit the most from VSM. Once you've made your selection, follow these steps with your VSM team:

1. Define your objective: Identify what you want to change for the customer as a result of the value stream mapping process. For example, you might want to improve the quality of a product or the speed with which you deliver a service.
2. Clarify your scope: Define the start and end of your value stream map. You can create a map that includes all of the steps between concept and delivery, begin with an inefficient part of your value stream, or end with a contract agreement instead of a traditional delivery.
3. Outline your process: List each step of your production process. Begin by speaking with team members from each department involved in the process to gather any needed insights. Your list should include non-value producing steps. Collect data about cycle times, lead times, inventory, and more to understand each step even further.
4. Create and evaluate your current state map: Using the information you’ve gathered, create a map that reflects the current state of your process. Work with your team to identify which steps are productive and where improvements are needed. This map will allow you to pinpoint areas of waste, like long process times or software downtime.
5. Develop a future state value stream map: Create a second map that illustrates an improved process that eliminates non-valuable steps. This will be the map you'll ultimately follow to reach your objectives.
6. Build an implementation plan: To start moving toward your future state, establish how your team will implement the new process. Include what metrics you'll keep an eye on to ensure you're on track to reach your objectives. You can also establish how frequently you'll review your progress and adjust your future state map (if needed) during the implementation phase.

📣 Achieve team alignment at scale with Easy Agile Programs

Join a demo

Continue adding value for your customers

Learning to see from your customer's perspective is crucial to ensuring you stand out from your competitors. Following the value stream mapping process can help you visualize where your team is producing value and where you're doing extra work that can easily be eliminated.

To continue adding value for customers, learn how Easy Agile Programs can help you dive deeper into your product’s customer's journey.

Try Easy Agile Programs for Jira

Keeping stakeholders in the loop is one of the key responsibilities of a product owner. A ton of work goes on behind the scenes before stakeholders can be presented with information about a product's deliverables and timeline. If sprints are your framework for getting work done and projecting delivery dates, the agile development team needs a way to make sure it's working through the product backlog at the right pace. The sprint burndown chart can show you the way.

In this post, we’ll talk about how to use a sprint burndown chart to monitor if your team is on track to complete its work and how putting user stories into sprints and epics generates even greater insights via user story maps.

What is a sprint burndown chart?

Image credit: Atlassian

First, a review: A sprint is a fixed period of time — typically between two and four weeks — that an agile software development team uses to complete a defined set of work.

A sprint burndown chart is a visual comparison of how much work has been completed during a sprint and the total amount of work remaining. It helps measure a Scrum team's progress, and it provides an easy view of whether the team needs to make any adjustments to complete its work for the current sprint iteration.

A burndown chart is a graph with a y-axis and x-axis 📉. The vertical axis measures the total amount of work that the team estimates it will complete during its current sprint. The horizontal axis shows the number of days remaining until the end of the sprint. On the chart are two lines: the actual work line (a line that represents the team's progress) and the ideal work line (a straight line from the top of the y-axis to the end of the x-axis).

You want your actual work line to follow your ideal work line as closely as possible. This would mean that work is being completed incrementally and at such a rate that it can be completed by the end of the sprint. Sprint goal achieved. 👍

A good practice for a team's product owner is to review the burndown chart on a daily basis. Doing so will allow you to detect if there are any progress issues happening in the sprint. For example, if your actual work line is trending above the ideal work line, then too much work remains to be completed by the end of the sprint at the current pace. We'll break down a few reasons why this may be happening later in the post. 😉

The sprint burndown chart is also a great tool to use during a sprint retrospective. Looking at this as a team can help generate talking points to discuss around the sprint retrospective's three key questions: What went well in the sprint? What didn't go as well as we hoped? How can we get better in the next sprint?

A primer on estimation methods

To measure effort on the vertical axis, we need to choose a metric.

Historically, traditional software teams used time to estimate the effort needed to complete a task or a project. For example, "I think it will take me three days to finish that user story." However, this approach can be risky because people tend to underestimate the amount of time it will take to finish a project.

The unit of measure on your sprint burndown chart's y-axis will depend on your estimation metric of choice. Let's review two common ones employed by agile sprint teams.

Ideal days

An ideal day is an estimate by a software developer of how many uninterrupted days it will take to complete a task. Assuming an ideal workday is eight hours of interruption-free work, the estimate could be stated as, "That user story will take me two ideal days." A benefit of this approach is that it accounts for work disruptions; however, it can be problematic because it often positions estimates as best-case scenarios.

Story points

Agile teams use story points as a relative estimate of effort as opposed to a time-based approach. Instead of saying, "I think this task will take me two days to finish," you would state, "I think this task is worth two story points." In this estimation technique, two story points are twice the effort than one story point.

Teams can use ideal days as a baseline to calibrate their story point estimates. For example, one ideal day can be equivalent to one story point, two ideal days to two story points, and so on.

A main benefit of using story points to estimate is that it allows teams to focus on relative measures of effort instead of thinking about how long it will take to finish a task.

Why your sprint burndown might be off track

A perfect actual burndown line is like Bigfoot — if it's been witnessed, it's probably a hoax. 😂

No team can perfectly estimate its work and develop at the exact pace represented by the ideal line. That said, if you notice large differences between your actual line and the ideal line (i.e., your actual line is much higher or lower than the ideal line), a number of things might be occurring:

• The team over- or under-committed to the amount of work at sprint planning
• Story points were added to or removed from the sprint after it started (scope creep)
• The estimated effort for some user stories is off

As a product owner, when you notice something that's off about your line after your daily review of your chart, you should mention that to your team members. The daily stand up is a perfect time to do so.

User stories and epics provide the big picture

User stories describe how a functional part of a product will work from a user's perspective. The common format of a user story reads, “As a [user role], I want to [user activity] so that I can [user goal].” For example, one might read, “As a new customer, I want to sign up for this product so that I can create my profile.”

User stories are placed in sprints to show what work (from the user's perspective) will be finished and by when. They can also be placed in epics to group them into themes within a product. Epics are widely used by agile teams to represent the high-level activity users will accomplish while using a product.

In our example above, an epic can capture all of the user stories that center around user signup, such as signing up, adding payment information, creating a user profile, and configuring notification settings.

If the sprint burndown indicates that the team is off track for a given sprint, then a combined view of sprints and epics can help you determine what impact that might have in the big picture. And, as we’ll see next, an interactive user story map can fix the problem.

User story maps: A view of epics and sprints

A sprint burndown chart is one of the handiest tools an agile software development team can use to make sure they're working and delivering at a solid pace. The burndown chart shows if any adjustments need to be made to your sprint.

User story maps provide another level of insights into team progress by:

• Showing sprints as vertical swimlanes
• Displaying epics as columns that represent the user journey through the product

This combination of swimlanes and columns unflattens your sprint backlog. It visualizes what the team will deliver and by when.

With Easy Agile User Story Maps for Jira, you can supercharge your ability to make adjustments to your sprint. It can help you:

• Create new user stories
• Edit story points on a user story
• Assign items in the backlog to an epic and a sprint

With this tool, teams can view their sprint statistics at a glance and take action. They can ensure they don't overcommit and that they're on track to achieving their sprint goals. It’s the most comprehensive user story map solution in the Jira marketplace for taking action to adjust your sprints from a big-picture viewpoint.

I fell into web development, that's how it feels without digging into the details. That does not sound like how you want to go about choosing a career but in reality, it was years of small decisions and nudges that I ended up doing work I really enjoy.

I grew up enjoying all things computers, but let's be honest it was mostly video games. In high school, I took all of the subjects available that had anything to do with computing, except for the software development subject ironically. I think because I didn't know about the potential creative side, I thought it was all hard maths. There was a subject I did where my major project was a batman flash animation, I was motivated in that class -- while others might have been bludging off and playing flash games, I was focused on making my flash animation and enjoying every minute of it.

Then it came time to do something after high school. I still didn't have a good idea of what I wanted to do so I choose a broad degree that involved computers — Information Technology at UOW. It was a mandatory programming subject in that degree that gave me a taste of software development, it involved building programs where the output was just in the terminal which didn't excite me much.

Then came a subject that everything started clicking together, Web Programming -- I think it was called. It combined design and code, used some newer web technologies, and was taught by lecturers who were clearly passionate about the web. We did projects like redesigning the movies page and I loved it. It also gave me a taste of making something that was useful, other programming subjects I did previously were just about outputting lines to the console.

After this experience it still didn't occur to me that I could get a job doing this, I didn't know anyone that was doing web development as a job. So after university, I went on a month-long holiday and tried not to think about what I was going to do when I got back.

When I got back I started applying for jobs, and a few of them for this role called frontend developer which was a new term to me. It was in the process of doing the take-home projects that I was given as part of the interview processes that I realised I could get a job in this thing I enjoyed.

It's been around 5 years since then and time has gone fast. In that time I was thrown into the deep end of many projects and have always finished them with more knowledge than when I started. Thanks to both the talented people that I have worked with and the challenge of the projects themselves.

I'm looking forward to the next chapter here at Easy Agile!

If you want to better understand the characteristics of SAFe agile teams, and what leads to the successes and failures. Register now for our upcoming webinar.

Do's and Dont's of Agile Teams with Adaptavist

Tuesday March 8 AEDT

REGISTER NOW

Large organizations use SAFe Agile to improve their operations. When you use this framework, you scale Agile to create a Lean enterprise.

This approach helps meet the challenge of delivering constant value. It also helps to support continuous improvement.

Another benefit of using SAFe® is that you get to plan and apply a predictable workflow schedule. When leaders link strategy with implementation, they increase their performance and productivity.

SAFe stands for scaled agile framework enterprise. You can use this framework to apply agile methodologies, such as Scrum or Kanban, to larger teams. SAFe training and certification courses help leaders plan and implement the philosophy.

In this article, you’ll learn about the benefits SAFe can offer your enterprise and how effective organizers lead and implement SAFe. You’ll also hear about training courses that can help.

Want to empower your team to implement the Scaled Agile Framework (SAFe)?

Try Easy Agile Programs for Jira

Free Trial

Major benefits of implementing SAFe

SAFe values alignment, transparency, quality, and execution. It inspires enterprises to adopt lean-agile thinking across multiple departments or teams. Lean methodology means higher productivity, reduced costs, and improved work quality. By identifying value streams and streamlining work processes as you implement SAFe, you can start to create a Lean enterprise.

💥 Achieve team alignment at scale: Easy Agile Programs product demo 💥

Register

By implementing SAFe, you gain the tools to support lean thinking. You create Scrum teams who understand what the user wants, how to deliver those changes with minimal time waste, and create efficient processes. SAFe will also clarify roles and processes so teams can quickly react to problems.

Many large companies have applied SAFe and report major benefits. One of these benefits is increasing employee satisfaction and productivity by as much as 50%. Then, there’s up to a 75% increase in product quality and time to market.

SAFe methodology teaches you to apply a systems approach to pain points, workflow management, and value streams. A healthy amount of cross-team collaboration can begin. The end goal is enhanced value flow.

The transition to using SAFe can take time and trial and error. Being brave enough to engage on a meaningful level and produce better quality outcomes is part of this new norm.

Beginning to use SAFe: The big picture

Using SAFe in your organization can be a major transition. You’ll need to consider how effective leadership and implementation will help make this transition.

1. Leading SAFe

Leading SAFe means building cross-functional teams and developing workflows that help your team get the most value out of planning. That way, software development teams can quickly respond to customer’s needs.

A solid SAFe leader improves productivity, product quality, and time-to-market.

Other identifiers of quality SAFe leadership include better team member engagement, which helps work better and feel part of a supported and supportive team. The value that individuals bring to the organization then increases.

Leading SAFe course

The Leading SAFe® training course is foundational. You’ll mainly learn about SAFe principles and their practices.With SAFe certification, you learn how to apply and scale the scaled agile framework for Lean and agile development. You’ll also learn how to plan and implement Program Increments (PI).

Once you have this information, you can guide transformation across your organization.

2. Implementing SAFe

To properly implement SAFe, you need to know how to coach agile teams through the SAFe framework and Lean-Agile mindset.

Before you can do this, you need to know how to identify and maximize value streams in work processes. In doing so, you’ll increase team collaboration. By increasing collaboration, you’re better positioned to produce value for product owners.

As you implement SAFe, you’ll constantly develop solutions to organizational problems and understand each person’s role in this framework.

Essentially, you start and sustain long-term change that increases value and profits. You then coach others on how to capture the value and apply SAFe principles in practice to achieve long-lasting change.

Implementing SAFe course

Implementing SAFe® is another foundational course. This training course offers an in-depth look at the SAFe Agile framework. It also teaches you how to apply your learning.

In this course, you’ll learn how to design a SAFe implementation plan, plan for enterprise transformation, introduce and launch Agile Release Trains (ARTs), and encourage the organization to be a lean enterprise. You’ll become a large-scale agile coach who teaches others to see and apply large solutions.

Implementing SAFe is ideal for anyone who wants to know how to lead transformation. It focuses on leading SAFe with remote teams. You get to find out how to create Agile Release Trains (ARTs) and show others how to design ARTs.

More SAFe roles and processes

As you learn how to incorporate SAFe, you’ll need to focus on empowering key team members and focusing on some crucial areas. SAFe training is available for some of these roles and processes.

• The SAFe Advanced Scrum Master coaches Scrum teams as they adopt the agile mindset.
• Lean Portfolio Management helps with cross-team collaboration as you adapt to customer needs.
• The SAFe Release Train Engineer is key for Agile Release Trains. This person works on PI Planning, among other events. This, along with the product manager, is a core position for leading SAFe to get the most out of value streams
• A Certified SAFe Program Consultant (SPC) leads change across the enterprise at all levels by coaching and training team members as they adopt the lean-agile mindset. The SPC also organizes and mentors employees to encourage ongoing engagement.
• You’ll need to empower teams to learn how to be a skilled member of an Agile Release Train.

Are you a Release Train Engineer or Program Manager struggling to effectively manage an agile release train or program?

Register for Easy Agile Programs Product Demo

As a proud Scaled Agile Platform Partner, Easy Agile Programs enables Release Train Engineers and Program Managers to effectively manage programs at a ‘team-of-teams’ level to deliver alignment at scale.

Try Now - Free Trial

More Agilist certification courses include training as a release train engineer and a SAFe Scrum Master. You can also take these two-day to four-day certified SAFe training courses to improve your competencies.

For advice on which certified SAFe courses are best for you, go through these FAQs to boost ongoing improvements in your organization.

SAFe training for better enterprise agility

Adopt SAFe to create a Lean enterprise with large-scale change. It encourages cross-team collaboration, systems thinking, and a lean mindset.

While SAFe can take time to implement, there are resources to help, including SAFe training courses. Choose to focus on team members and processes that can most benefit from extra guidance.

You can also follow the Easy Agile blog, podcast, and learning hub for extensive guidance on agile principles, roles, and tools.

Streamline visibility and provide transparency of your Program

Easy Agile Programs Product Demo

Register Now

Agile retrospectives are a time to reflect on the sprint before. During this time, the Scrum team decides on the agile retrospective template to use during retrospective meetings. A sprint retrospective template provides a structure for retrospective meetings. These retrospective templates guide agile teams in analyzing their previous sprint.

What is an agile retrospective?

Teams use agile retrospective meetings to improve the next sprint. As the team members move through the product life cycle, they gain new learning after each sprint retrospective, which they apply to the next sprint.

The focus of the sprint retrospective meeting

Sprint retrospective meetings ask four questions, as listed below. The agile team places these four questions in the four quadrants of their retrospective template. (Note: Team members can use a whiteboard or sticky notes to set up their meetings. Or they can use Jira software to facilitate remote team meetings in real-time.)

Co-located agile teams can also use whiteboards and sticky notes to do an agile retro. But for remote teams, agile retrospective template software allows all team members to participate in sprint meetings.

Here are the four question areas for discussion:

• What went as planned?
• Where could the team have made improvements?
• What should team members do in the next sprint?
• What confuses the team?

1. What went as planned?

The agile retrospective requires in-depth analysis. Team members can chat about what they enjoyed, which methodologies worked for them, and what agile ideas are worth taking into the next sprint.

Typical questions that agile teams ask in this first stage include:

• What were team members happy with?
• What actions delivered positive results?
• What processes or actions should the agile team continue with?
• Should anyone receive a special thanks for their contribution?

2. How could the team have improved?

Stakeholders examine where they went wrong and try to find the root cause of the issues. Brainstorming involves what they could have tried previously, where improvements are needed, and what processes or actions they can test in the next sprint.

Here are some ways to make this question more concrete:

• What has the team previously not tried that might work?
• What is one new thing that we could attempt?
• What new tactics or actions can we test next?

3. What should team members do in the next sprint?

In this part of the template, the team explores new ideas for how to improve their follow-up approach. New ideas can be risky, so the Scrum team should carefully consider opportunities for improvement. The idea in this questioning phase is to clarify problem areas, where value was not produced, and what was puzzling in the previous sprint.

In this round, the team should discuss:

• What didn’t work?
• What did the team do that did not produce value?
• Which areas specifically require improvements?
• What did not go as anticipated?
• What issues in the previous sprint are confusing?

4. What still confuses the team?

In this section, the team should focus on areas that weren’t as effective or did not go as anticipated and what areas need improving. Other relevant areas include where the agile team didn’t deliver value, focus areas that require development, and what was confusing about the sprint.

Here, it’s important to talk about:

• What questions still remain unanswered?
• What outcomes still require further investigation?
• Is the team following processes that don’t deliver clear value?

Through a process of iteration, the Scrum team brainstorm to come up with real-time solutions to take over to the next sprint. Using retrospective ideas, the team populates the four quadrants of the retro template, producing a visual representation of their post-mortem.

Scrum teams can apply the four questions above in other retrospective templates or customize a template to conduct their post-mortems.

Retrospective template options

Team members can choose from retrospective templates to customize their sprint meetings.

Sprint planning can benefit from any of the agile retrospective templates below:

• The start, stop, continue template
• The four Ls retrospective template
• A starfish retrospective
• Sailboat retrospective
• Glad, sad, mad
• Mad, sad, glad

1. Start, stop, continue

In the “start” part of this retro, the agile team looks at the actions they’ll take in the next sprint. “Stop” refers to looking at the recently completed sprint to examine what didn’t work and the actions that the team should no longer take. “Continue” means identifying what worked in the current sprint and should be taken over to the next cycle.

2. Four Ls

Agile teams use this retro template to understand what they “Loved, Learned, Loathed, and Longed for” at the end of the sprint iteration. The team calls out what they appreciate, what the sprint taught them, what went wrong, and what they would’ve wanted more of (coffee, team members, time, etc.).

3. Starfish

Instead of using a retro that focuses on what worked and what didn’t, the starfish highlights degrees of efficiency in deliverables. Teamwork involves rating action items as levels of effectiveness to determine what methodologies they should keep, discard, and apply in the next round.

4. Sailboat

Scrum teams use the sailboat retro to determine their trajectory in unknown waters. Applying the sailboat retro means knowing what approaches inhibit progress, what new approaches will reap desirable outcomes, and establishing a direction for sprint planning.

5. Mad, sad, glad

The mad, sad, glad sprint retrospective is a technique that concentrates on the emotional status of teams. Scrum teams ask each other questions to create positive emotional support. These questions are also aimed at morale-boosting to create a positive atmosphere that supports teamwork and continuous improvement.

The agile retro can follow any template they choose or select one and customize it for their specific needs. Whatever they do, teamwork is vital to the success of continuous improvement.

Decide on your retro template today

Now that you understand how the sprint retrospective template works, you can customize yours for joint teamwork.

Instead of focusing on longed-for outcomes and functionalities, Easy Agile can help your Scrum team move from sad to glad.

Team retrospectives right inside Jira

Looking to improve how your team is working together? Easy Agile TeamRhythm helps you turn insights into action with team retrospectives, to improve how you’re working and make your next release better than the last.

TRY EASY AGILE TEAMRHYTHM FREE FOR 30 DAYS

There's a lot in common between a Product Manager and the executive president of a professional sports club. Don't buy it? Well, you should 😋, and here's why.

• Both are experts in their businesses.
• They both know what it takes to win. 🏆
• They're great leaders of their teams.

Stay tuned because this article will give you a grasp of how unique the product management role is. You'll learn what their responsibilities are and more.

And if you landed a job opportunity as Product Manager, we'll give you a hand with mastering your craft. 🥇

But first things first: defining the role. And once you know this, we’ll move on to exploring their tasks, unique characteristics, and the challenges they face.

What's a product manager?

For context, let's start with product management’s role in PI (Product Increment) Planning.

According to our Guide to PI Planning, the Product Manager must understand the customer needs and validate solutions against those needs. That’s the starting point and foundation for their role. But that's still generic. 🤔

The Product Manager is THE product expert. That makes them the best-equipped team member to make strategic decisions about the product. These decisions affect the work of a lot of people in a company.

The Product Manager is a product visionary and strategist. They monitor and analyze the market competition. That's how they define a unique product vision and product strategy. Their ultimate goal is to add unique value to the market based on customer needs.

The Product Manager decides what products or product features to build and in what order. This means they prioritize new products or new features in an existing product. Defining a product vision and a product strategy is intimately related to prioritization. They must do their best effort to maximize both customer value and business value. Not an easy challenge!

The Product Manager leads the teams responsible for developing a new product or improving an existing one. They usually work across cross-functional teams, so leading them demands a great deal of organization from the Product Manager. Plus, they need the ability to bridge, communicate with, and supervise engineering, marketing, sales, and customer support staff.

The Product Manager participates in all stages of product development, from planning and conception to launch or release. But what tasks do they do?

The product manager's tasks

You already know some of the product management tasks. But here's a comprehensive list of product management tasks:

• Understand, identify, and, if necessary, represent customer pain points and business challenges.
• Manage the process of generating new ideas for products or features, and decide which ideas to move forward with.
• Describe a product vision, and align all teams with that vision, especially in large companies.
• Create and maintain the product roadmap.
• Design a strategy for product development.
• Limit the project scope.
• Rank features against the product strategy, business goals, customer value, and customer or user feedback.
• Specify the requirements for each feature.
• Define the launch or release process, which comprises phases and milestones.
• Manage dependencies within and between phases.
• Identify the deliverables and corresponding due dates for the cross-functional teams.
• Coordinate the activities of each team from product development until launching the product into the market.
• Validate product design and implementation.
• Ensure the successful launch or release of the product.

Now, are you working with Scrum? If so, you might be wondering about the differences between the Product Manager and the Product Owner.

Product managers vs. product owners

Although they may interchange tasks, they're distinct roles. In short, the latter works towards realizing the product vision and the product strategy that the first defines.

The Product Owner works more closely with the software development team. On the other hand, the Product Manager interfaces directly with customers, users, and partners.

Sometimes, when there's no Product Manager, the Product Owner steps into this role. However, in that case, there's little time to coordinate the work of all teams around the same product vision.

But regardless of whether there’s an existing Product Owner, there are key ingredients that make good and great Product Managers. Let's discuss that next.

What makes a great product manager?

The characteristics of a great Product Manager consist of technical skills and personality traits. So, besides technical skills, they should have a high EQ (emotional coefficient). This means:

• Showing customers and users empathy during any communication with them
• Developing trustworthy relationships with internal teams and external stakeholders
• Inspiring and motivating team members
• Discretely persuading people to take the necessary steps to achieve a common goal, which starts with listening to them
• Avoiding bias in the preference for solutions by being user-centric and ensuring that solutions answer user needs
• Managing stress and performing well under pressure
• Demonstrating the urgency of task completion without causing panic
• Knowing how to ask the best questions to the right people at the right time
• Delegating the power of decision-making by giving teams a methodology and criteria for escalating if needed
• Daring to confidently make strong statements about priorities, advocating for any of their decisions
• Having the courage to choose whom to favor with a decision, whether it’s engineering, marketing, or sales
• Not being afraid of changes such as defining a new product strategy for business growth
• Reading the emotions of customers, users, and internal team members, and capturing their concerns

If they tick all or most of the above, the Product Manager is on the way to being emotionally intelligent.

Typical results from an outstanding product manager

If the Product Manager has a high EQ, they'll be the best at:

• Growing teams to become high-performing
• Negotiating with customers, users, partners, and people from different departments
• Resolving conflicts that might get in the way of cross-functional teams that make successful products
• Getting more funds, top talent, and other kinds of support or resources
• Prioritizing according to customer pain points
• Making sure the development team knows users actually need the changes they're implementing
• Obtaining the best trade-offs between the different individuals and teams involved and interested in a product's development

Ultimately, customers will trust the Product Manager to fix problems with the product. Plus, engineers will accept going the extra mile to incorporate a microfeature on short notice. And if the Product Manager is always calm and cool, management will trust their work.

At this point, you know how personality matters to the success of the product management role. Next, discover how the type of product and its users also affect their work.

The right measure of technicality

The more complex a technical product is, the more experience the Product Manager should have with building similar products.

On the other hand, for a less complex technical product, experience with launching products and supporting customers is enough.

Summing up, the Product Manager knows how to talk with the users of a product and the customer. Additionally, they have at least a basic technical understanding of the product.

But wait! That's not all. Product Managers also do some magic when interacting with engineers and top management.

Connecting with engineers and top management is key

The Product Manager should establish, maintain, and manage a relationship with the engineering team and top management.

Relating to the engineers

The relationship between the Product Manager and the engineering team depends on the company's view of the product development process. And it can be done in three different ways:

1. The Product Manager hands the product requirements to the engineering team, which transforms them into technical requirements.
2. Engineers develop the product, which the Product Manager validates and sometimes monetizes.
3. The Product Manager and the engineering team collaborate closely to develop the product.

❌ The first approach is not that agile or quick. In fact, it resembles a waterfall approach to product development that takes ages to get to a viable product. Also, engineers focus on coding and might lose focus on UX (user experience).

❌ The second alternative might innovate by creating new customer and user needs. Nevertheless, user feedback might come in too late to align the product with user needs without costing more.

✔️ Last, in the third option, the Product Manager and the engineering team gather requirements and make decisions together. The first doesn't tell the latter how to code, and the latter doesn't tell the first how to prioritize. The result is better UX, faster product development, and better product quality. And everyone's happy! 🎉

Relating to top management

The Product Manager should work closely not only with the engineering team but also with top management. The involvement of top management in the product development process is crucial to product success and the success of the product management role.

The more top management is involved in product development, the more the Product Manager is in a support role. And that's truer for young companies.

In a startup environment, the Product Manager often doesn’t lead the idea generation process. Another downside of young companies for those professionals is that they have less influence on the product vision.

It's time to consider how a company’s maturity impacts the product management role.

How company maturity influences the product manager

The company's maturity influences the Product Manager's performance and success. In a startup, this role should be more versatile. On the other hand, the role is narrower and has clearer boundaries in a mature company.

So, in a startup, the Product Manager might be responsible for market research, pricing, and customer support. That's because startups are growing companies that often have a tight staffing budget.

But despite being highly dynamic environments, young companies represent a land of opportunities for Product Managers. They might influence the business strategy more as the company grows. And they might also have a say when it comes to using or assigning company resources.

Finally, what the Product Manager lacks in a startup, they have in abundance in a mature company. An established customer portfolio is an example of that.

Product managers are the product’s backbone

The product management role is an essential element of any technology company. Perhaps their major responsibility is to define the product strategy and play a key role in Sprint Planning or PI Planning. But they also prioritize the planned features for the increment beforehand. And they coordinate the work of teams from different departments.

At a higher level, the Product Manager must communicate with those teams. The goal is to make sure everyone is on the same page. And ultimately, they're strong leaders who trigger the development of useful and profitable products.

If you're a Product Manager looking for more tools to help manage your product, check out Easy Agile's tools. Our roadmapping tool for Jira might help you sequence features for delivery to your customers. And Easy Agile's PI Planning solution for Jira might help you visualize program dependencies and milestones, plus do cross-team planning.

You can find dozens of product management tools that fit SaaS goals.

These tools vary in features, functionality, and pricing. However, one thing is certain: Product management tools are more supportive than ever before.

Find out what product management can best support your software development.

What are product management software tools?

Product management software tools help to guide software development teams through their workflow.

Product management tools can help team members conduct research, create assessments, do iterations, and plan their product launches. Some tools even support roadmapping product development, so they can support agile teams.

Development teams can use roadmapping tools to:

• Streamline product strategy
• Draw up their product plan
• Create their product roadmaps
• Develop user journey maps
• Manage backlogs
• Conduct research on customer needs
• Improve prioritization of product features
• Determine the length of their Scrum sprints
• Analyze data for their product research
• Do process mapping
• Manage product releases
• Improve how agile teams collaborate
• Create new products
• Deliver better products
• Message team members

Using product management tools are ideal when working with remote teams. It is also the solution to increasing collaboration across cross-functional teams.

Many or most of these product management tools also integrate well with existing software, so it’s no big deal to customize existing systems. You can also customize many of these product management tools to meet your product team’s needs.

Here are eight of the most recognizable product software tools available to start your new roadmapping journey.

1. Jira

Jira is typically seen as the best product management software tool for software development. However, many other industries use Jira for roadmapping and managing their projects. This popularity is due to the fact that Jira offers a free plan, but it goes deeper than that.

Jira is the ideal software management tool to use in managing Scrum, Kanban, Waterfall, and other agile methodologies. The user interface is intuitive, making it easy and convenient to use whether you’re a product manager for software or other products. Because it is also a convenient tool, you can use it to assign tasks and manage projects and product development.

Product managers can easily keep track of workflows, agile team responsibilities, and tasks. You get to see where backlogs are building in Scrum or Kanban. You can also manage velocity charts, burndown charts, release burndown and sprint reports with Jira software.

You can also include software like Slack, GitHub, and others to round off your Jira product management tool.

Some of the key features you can anticipate in this software include:

• Visually capturing the product vision to develop better products
• Collaboration tools to keep teams on board in real-time
• Gantt charts to view project and product progress
• A Scrum or Kanban board
• User-friendly roadmaps
• Milestone tracking
• Portfolio management
• Comprehensive Agle reporting
• Extensive automation of the product management process
• The ability to connect codes with issues

In terms of pricing, small businesses often go for the free plan. Jira’s free plan allows 10 users to access roadmapping and other features simultaneously. The paid plan is about $7 monthly for each user.

Agile teams using Jira can benefit from Easy Agile Programs for Jira. It helps teams align on their goals, focus on features and epics, and view dependencies. However, all Easy Agile plugins work with Jira. They simplify everything from PI planning to creating personas and roadmaps.

2. Trello

Trello uses a card system to manage Kanban and other product development workflows. When the administrator sets up the Trello board, product teams get a visual representation of workflows. They can see user stories, who is responsible for tasks, and an overall view of workflow and product life cycles. All these features and others make for an excellent roadmap tool.

The disadvantage of this system is that it doesn’t have a calendar. Another drawback is it offers basic folders for task categorization. It will be difficult to use Trello for Scrum, for example, as you have limited access to folders and there are no subfolders. You can however access multiple user stories to streamline workflows for simple projects.

Despite these drawbacks, Trello does include workflow automation, courtesy of the Butler robot. This little robot feature enables you to set certain rules and calendar triggers so that you can automate repeating assignments. Trello is probably better suited to startups or tracking progress when you have a small salesforce.

Because the Trello platform is simple (but intuitive), team collaboration is convenient. Communicating via Trello is also user-friendly, helping product teams to immediately see who is doing what and task deadlines.

While Trello defaults to the Kanban methodology, you can use it for other project types.

Several features you can look forward to on Trello, include:

• Prioritization of tasks
• Tracking deadlines
• Gantt charts
• Kanban board
• Tools for Agile team collaboration
• Resource and task management
• Automation of workflows
• Tracking team member progress
• Various templates

Trello has a free plan where product managers can use up to 10 boards for each of their teams. You can also purchase the pain plan on a yearly basis, which costs around $10 per user.

3. Wrike

Wrike is as much a tool for streamlining workflows as it is for managing product development. Wrike is flexible, adaptable, and dynamic and is a tool designed for better product decisions.

You can use it for small product management, single client management, or as an enterprise-wide tool for product management. Wrike is also versatile enough to use in software product development or marketing. This platform also has a special tool for marketing, making it easier to manage salesforce operations.

Wrike is customizable, so you can include Gantt charts and Kanban boards to improve team member collaboration. Another function of this platform is its Work Intelligence AI tool which product managers can use for automation and predict product risk.

Wrike works well with Jira, Slack, GitHub, Dropbox, and several other tools. You can also customize other integrations to tailor Wrike for product management teams. If you want to add software which this platform doesn’t support, you can. You simply create the solution you need.

The most prominent features of Wrike are:

• The ability to integrate third-party applications
• Its comprehensive, versatile API
• Managing multiple template options
• Permission and access control
• Importing and exporting data
• Integration of spreadsheets and tables
• Convenient task management
• A user interface for dragging and dropping
• Categorizing and structuring product tasks
• Calendar and timeline control
• Files and documents management
• Tracking activities and progress
• Filtering of data
• Stats and reporting
• Shared or public workspace

Wrike offers a free plan for the use of simple features, but you need to pay about $9.80 a month for each user to access more complex functionality.

4. Productboard

Productboard is right up there with the likes of Zendesk. It provides one of the best features for gathering user feedback. As every software development team knows, user feedback can make or break product success. With this product, you can categorize customer feedback, turn this into valuable information and prioritize this feedback.

Productboard lets you track their feedback during the lifecycle of each product via a portal. This portal supports idea exchange and management, which team members use as inputs to increase product value. This software tool is also great for collecting use cases and understanding user behavior to create the right products for customers.

You can use Slack and email with the Productboard, but if you want additional software integration, you must arrange this yourself. Fortunately, the API in this product is user-friendly to make this happen.

The main features of Productboard include:

• Storehouses for product feedback
• Customer segments that are particularly dynamic
• The ability to prioritize and categorize customer feedback
• Transforming feedback into valuable insights
• A powerful system for value assessment
• Roadmapping tools that you can customize
• Prioritization of tasks

You can get an annual Productboard basic plan at around $20 a month for every user.

5. ProdPad

ProdPad takes the user experience into consideration. It has a lean roadmapping function that you can use to highlight goals and objectives. You can experiment with this product software tool to include user feedback in product development. ProdPad is also known as being among the best product management software tools on the market.

The product roadmap tools are simple to use and include color coding for roadmapping. ProdPad has an easy drag-and-drop feature, privacy settings, and you can use the priority checkpoints as you need.

Development teams can access an ideas management feature to create priority charts. Here, they can see how backlogs influence impact and effort charts in workflows. You can also simply import data from other sources to boost new product development if necessary.

One more feature that characterizes ProdPad is the ability of team members to see associations between user ideas and product development. They can also develop customer lists to question further about their product experiences.

You can collect use cases and understand user behavior better. You can then use all this information as inputs for new product development.

Features that you can expect from this product management tool are:

• Idea generation and capture
• Capture and storage of customer feedback
• Integration with apps that support customer feedback
• Integration with other third-party apps
• Priority charting of ideas
• Lean product roadmaps
• Product roadmapping based on objectives
• Creation of customer portfolios

You can purchase ProdPad’s Essential Plan at about $149 per month for annual billing. This plan allows you to use three administrators or editors for product planning.

6. Asana

Asana is also a useful management platform. You can use it as a solution to roadmap workflows. Asana is popular among small business startups and larger enterprises.

This management solution is cloud-based. It enables team members to share their workspace and assign and track tasks and work progress. Asana is also an excellent platform for team members to collaborate.

You don’t get much customer support with Asana. And, although not ideal for complex team management, Asana has many redeeming features, some of which include:

• Excellent team messaging and collaboration
• Ideal for outlining detailed goals
• Efficient for managing multiple tasks and team members
• A user-friendly dashboard
• Tracking of milestones
• Automation
• Several templates option
• Project planning functionality
• Multiple analytics and reporting options
• Managing resources
• Tracking of time and expenses

Asana has a free plan if you can cope with limited features. Paid plans begin at approximately $10.99 per month for each user. The company bills annually.

7. GLIDR

There are multiple management solutions for streamlining product workflows. GLIDR offers one more platform from which to achieve product software development goals. You can develop detailed product plans that meet customer expectations. GLIDR highlights the customer experience, so places their feedback at the forefront of the best product deliverables.

You can manage product research, use cases, and user behavior on this platform. You can then create product specs, link ideas, create viable user stories, prioritize features, and much more.

GLIDR provides several board view options that help software developers to create themes from ideas. You can also categorize ideas by their status, fill in timelines, or show these ideas on Kanban boards.

Other helpful functions include the ability to integrate apps such as Intercom and Zendesk with GLIDR. You can also link Jira and Trello with this product management software.

Product managers and teams can use GLIDR to streamline their workflows, track product progress, create reports and transform roadmaps into the best products possible.

The primary features of GLIDR include:

• Product canvasses
• Public roadmapping
• Options for research and experimentation
• Trend scores to rank ideas
• Prioritization of features
• Activity feeds
• Progress tracking and monitoring
• User-friendly dashboards
• Reporting that you can export via PDF format

You can test GLIDR for free for 14 days. Then, the cheapest option is about $8 per person, per month for a team of five people. GLIDR bills annually and has three other plan options that give you access to more features.

Up your game with Easy Agile

One way to up your product management software game is to take advantage of Easy Agile resources. You can either use our Jira apps to integrate with existing product management platforms or give your existing system a boost.

Select from apps for Kanban Workflow for Jira or boost product development performance with User Story Maps for Jira.

Up your game with Easy Agile Roadmaps for Jira to guide your team to product success or use our Programs for Jira for Program Increment Planning.

Whichever apps you choose (all of them?), you can improve product team management with the best product management software available.

Simply developing a product doesn’t mean it’ll be a success. Plenty of elements determine how well a product is received — and a lot of that begins with product launch planning.

How will you unveil your product to the world? Who will be able to access your product when it first launches? What features do you need for the product's initial development, and what features should be saved for further down the road? How do you make sure everything is ready in time for the launch date you’re hoping for?

Product launch planning melds your development strategy and your sales and marketing strategy to ensure every department works together and aligns on key goals. It’s a whirlwind of a race to the finish line, but it’s also an exciting time for product developers. How will your product be received? What will customers and stakeholders think?

In this post, we discuss seven key strategies for successful product launch planning. Time for takeoff! 🚀

1. Set clear goals and define what success looks like

Set clear objectives and be realistic about what you hope to accomplish. Setting lofty, unattainable goals will distract from what matters most, and it can lead to disappointment, lack of motivation, and reduced morale.

Be clear about who on the product team is responsible for what and ensure team members outside of product development, including sales teams and marketing teams, are involved in product launch planning.

How will you go to market? What do you hope to accomplish with your launch? What product launch planning needs to happen before you can move forward? What pre-launch deliverables are critical to moving development forward? What roadblocks could prevent your success?

When you understand what you are trying to accomplish, it’s easier to tell when you’re successful. Don’t leave anything open-ended so that everyone on the team knows what you’re working toward and how to get there.

2. Get to know your audience

Great products are developed when customer needs are at the forefront of decision making. No matter what stage of product launch planning you’re in, you should always keep the customer journey top of mind. Consider how each decision you make brings value to your customers.

Customer personas describe important details about a target audience, such as pain points, behavioral patterns, demographics, goals, and buying habits. Deeply understanding who you are building a product for and what they need is vital to a successful product and a successful product launch.

Easy Agile TeamRhythm supports user story mapping, helping teams empathize with customers so that development and launch decisions can be made based on what will provide the most value to your target market.

3. Gather feedback and test, test, test

Test, test, test! We can’t say this enough. You need to continually test, ask questions, and gather market research.

Get your product in front of stakeholders and customers frequently to gather feedback along the way. The more you learn as you develop your product, the more issues you will sort out as you go, and the better the project will be in the end.

The testing process will also give you a deeper insight into what your users are looking for, so you can better meet customer needs. How do they interact with the product? What issues arise? What questions do they have? Do they understand how to use it? What features are they looking for?

Gather as much feedback as possible so you can continually improve the product leading up to the launch. Bring your stakeholders and customers into your process to better understand their needs and how you can provide consistent value.

4. Use comprehensive tools to track product launch planning

Product launch planning is a complex process with many moving parts, team members, and deadlines. Having the right tools is essential to the success of the launch. The whole team needs to be able to see what is planned, what is expected, and how each piece leading up to the launch is connected.

Establish a clear product launch plan template that guides the team forward. Backtrack from the desired launch date to create a launch timeline that recognizes everything that needs to get done before the product is put out into the world.

A product launch roadmap is an effective tool for tracking your progress. Roadmaps help teams align their vision, keep track of specific product launch dates, and provide a clear visual of the most critical prioritizations.

Learn how to create a product roadmap template with Easy Agile Roadmaps for Jira. They help teams align around a product vision and launch strategy to continually bring value to customers.

5. Focus on an initial great product, not features

Focus on your minimum viable product first. This is your top development priority before launching — no matter how tempting other fancy features may be.

Fancy features may be appealing, but they could slow down development, add unnecessary stress on the team, and cause unwelcome issues right before you’re supposed to launch your product. Put in the work to develop a product that meets stakeholder needs and delights customers. If this goes well, there will be plenty of opportunities to zero in on other features down the road.

6. Expect the unexpected

No matter how much feedback you gather and how many tests you run, there are always surprises when it comes to launching a new product. Launch day may not go as smoothly as you hoped. It’s okay if things don’t go exactly as you expected, so long as you’ve prepared for these possibilities and can adjust.

Extensive product launch planning will help you navigate surprises. It also helps to practice the motions beforehand. Give yourself time before the new product launch to review and practice the steps that need to play out. Rehearse your process to smooth out as many possible hiccups as you can. The extra time you spend running through the motions will also help ease the nerves of the team members involved in the launch process.

7. Hold a retrospective after the launch

After all is said and done, there’s still one more important step to your product launch planning. A retrospective helps teams examine the launch strategy and how everything played out. What went well? What didn’t go so well? And what can be learned from the process?

Even if you won’t launch another product any time soon, a post-launch retrospective is a great opportunity to learn from your experience. You can take these insights and success metrics into account when launching future features or other products down the road. Plus, it gives the team a chance to debrief after launch activities conclude.

Let’s recap those strategies one more time:

1. Set clear goals and define what success looks like.

2. Get to know your audience.

3. Gather feedback and test, test, test.

4. Use comprehensive tools to track product launch planning.

5. Focus on an initial great product, not features.

6. Expect the unexpected.

7. Hold a retrospective after the launch.

Learn more on the Easy Agile blog

There’s more where this came from. We’re dedicated to helping teams work better using agile tools and practices. We make simple, collaborative, customer-focused plugins for Jira, and we regularly publish articles on strategies, agile information, and how-to guides for product managers and agile teams.

Follow us on LinkedIn for the latest agile resources, guides, and product news.

💬 “We know we’ve created something special, an ESOP like no other…”

Nick and I started Easy Agile after returning home to Australia from living and working in San Francisco where we witnessed the good and not-so-good sides of startups.

We were lucky to experience first-hand the amazing career opportunities and growth that working for successful companies such as Atlassian and Twitter can provide. On the other hand, we also saw companies start-up, consume vast amounts of funding and flame out. There was a terrible toll taken on our founder friends and their families who put life balance aside in pursuit of success at any cost.

We took all of this into consideration when we started Easy Agile. We didn't want to default to the standard VC-backed journey so we set our own pace. We wanted to learn what it was to build a customer-funded, sustainable growth product business, even if that meant a more difficult learning curve as we carved our own path.

Well, that was 6 years ago and here we are happily customer-funded for over 5 of those years, growing at an exciting rate, we believe is healthy and sustainable. We're proud that we're bootstrapped and we're not really looking to change that.

💬 “We can do things differently”

One part of the common startup playbook which we did want to retain is employee ownership. We have been dying to introduce an ESOP for a long time, however, being bootstrapped and customer-funded makes creating an Employee Share Option Plan a bit more complicated. Off-the-shelf plans are usually based around the concept of a planned (or hoped for) exit event, as it’s the only time cash-burning companies can realise value for shareholders. This would not work for us and we were looking to provide a more accessible way for our team to realise the value gains as we grow.

We also knew in our hearts that our ESOP had to be a reflection of Easy Agile's values. We understand the wonderful people that make up Easy Agile are all at different stages of their careers and have different needs financially so we designed our ESOP to take this into consideration.

Our ESOP also had to be generous. Nick and I really want to continue to pay forward the generosity we’ve been privileged to experience and enable our entire Easy Agile team to have the opportunity to achieve financial freedom. We hope one day many of our Easy Agile team will find themselves as founders of successful companies and continue this tradition with their own ESOPs. 🤞

Now our ESOP is live, we know we’ve created something special, an ESOP like no other. There’s no standard template for what we’ve built as very few startups or scale-ups in Australia are in our position. We’re growing fast, we’re profitable and we aren’t constrained by investor demands.

It means we can do things differently.

How the Easy Agile ESOP is different

1. Generous valuation from the start

For our initial grant of options, we valued Easy Agile using a super-low valuation. This gives our initial option grant the highest immediate appreciation of value on paper we can give.

This type of valuation based on our "Net Tangible Assets" (NTA) is made possible by the Australian Start-up Tax Concessions. Being a software company, our assets are limited to the cash in our bank and some laptops. We have no debt.

At the same time, we also have a “Fair Market Value “(FMV) calculated similarly to other SaaS companies. It worked out that our NTA valuation for our initial grant was 44 times lower than our FMV valuation meaning by accepting your options, on paper, your options are already worth 44 times more than you will ever pay to exercise them.

We feel this is pretty special.

2. Real $ value for our team more often through an Option Buy-Back

We understand that our team members all have different needs financially. Some have mortgages. Others want to buy a house. Others are happy to rent and invest in other things.

We’ve ensured our team has the opportunity to realise an exit at a time more suitable to their personal needs.

Our Option buy-back scheme allows Easy Agile, to offer to buy back vested options from our team at the Fair Market Value. Our team can choose to take advantage of the company’s growth and turn some of their Options into cash far more readily than waiting for an exit event (IPO, secondary, sale, etc). This is a profoundly different concept from most SaaS companies. They can also choose to hold onto their Options for the long-term gains we all work together to achieve.

3. Dividends

Most SaaS product companies don't really get to a dividend issuing phase. They simply don’t have the profits available. Once again, we're different here. We have a sustainable growth trajectory enabling Nick and I to issue dividends to shareholders over the course of the life of Easy Agile. We will continue to do this in the future and so Easy Agile shareholders will benefit long-term with dividends and voting rights that come with Ordinary shares.

4. You can nominate a trust

We allow you to nominate a trust to hold your share-holding. Nick and I are fans of getting serious about financial planning and literacy (just ask our team!). We wanted to give our team the most flexibility we could, so we allow for our team members to nominate a trust to receive their options instead of themselves personally.

What’s next?

We’re thrilled to be at this stage in our journey as it enables Nick and I to better reward the team who have built Easy Agile with us.

We’re even more excited about the journey ahead. We have big plans, the ability to invest in our team, our products, our growth and most importantly the impact we are having for our customers.

We’re always hiring so please reach out if you want to be part of the team that’s leading the way in helping companies around the world be agile.

💬 “We hope one day many of our Easy Agile team will find themselves as founders of successful companies and continue this tradition with their own ESOPs”

For a lot of people, 2020 isn’t quite going as expected.

Maybe you’ve had a conference or two cancelled (like the Atlassian summit 😭). Perhaps your big team planning event is on the backburner. Or maybe your entire workforce has been told to work from home until further notice.

Amazon has stopped all non-essential travel and a number of big tech companies have encouraged employees to work from home, including Apple, Google, Microsoft, Twitter, Facebook, and HP (in some or all regions).

You think you’re disruptive? Well, clearly you haven’t met COVID-19!

The new pandemic has shaken things up. Record numbers of organizations are looking for ways to quickly adapt and transition their teams to working remote. It’s a huge challenge when you consider that agile is typically designed for face-to-face interaction - especially critical events like quarterly PI Planning.

We’ve put together some thoughts to help you quickly transition your team to distributed agile, based on our own experiences and working with big organizations who have been working with remote team members for awhile now. First thing’s first...

1. Don’t panic (about distributed agile)

We’re not qualified to tell you if you should panic about the pandemic (seriously though… you don’t need that much toilet paper). But we are qualified to tell you that a remote workforce isn’t as scary as it sounds. You’re going to be just fine.

Organizations like yours have been doing their thing with a distributed agile team for years now. One of our customers has a large distributed team and only does remote PI Planning. It's possible to pull it off.

2. Lead people on how to work from home

Some of the people on your team probably haven’t worked from home before. At least, not for an extended period. So, offer guidance on what’s expected and how they can make the most from working at home.

You know... like business up top, sweatpants on the bottom, and no one on the conference call will be any wiser.

But seriously, it’s a good idea to share guidance like:

• What equipment they’ll need
• A list of software and apps to download (with licensing info)
• Where to find information and access files (a single source of truth is best at all times, but especially when things are already a bit overwhelming)
• How to communicate virtually
• Ideal environments for focus and productivity
• How to block out noise and distractions
• Expected work hours
• How to switch off and take breaks

But a little guidance will go a long way in helping everyone feel more “at home” with the new work situation.

3. Encourage information sharing

You might already have a distributed agile team who are experienced with working remote. So, encourage the experienced remote workers to champion the practice and lead others.

Create a Slack channel or other environment dedicated to discussions about working from home, so that people can share tips and experiences, and ask questions. At Easy Agile, we've created a #remote channel to share our setups.

4. Get the right tools

If your team is working remote for the first time, they might not have all the bits and pieces they need at home to do their job, attend meetings, or show up properly to a remote PI Planning event.

Depending on their role, they may need:

• Computer - A desktop and monitor setup or a laptop with sufficient processing power for everyday tasks
• Meeting equipment - Webcam, headphones, and working mic
• Your preferred communication apps - Slack, Zoom, Google hangouts, Skype, or Microsoft Teams
• Security measures - Password managers, VPNs, and antivirus software
• Your project management tool - Jira, Trello, Asana, or Smartsheet
• Easy Agile Programs for PI Planning in Jira

5. Look at this as a pilot

More people want to work from home and it makes a lot of sense for businesses to encourage this new way of working. It can save a lot of money (one estimate suggests $10,000 per person per year) when teams stay at home. And you can save hundreds of thousands per PI Planning session when you don’t have to pay for flights, accommodation, and event space for a team of up to 100.

The remote work trend isn’t going away - even after the pandemic dies down. So, look at this as an opportunity to try distributed agile if you haven’t already. You could find it’s a better, more cost-effective way for you to get stuff done and give your employees what they want.

6.Trust your people

Nobody likes to feel watched while they’re working 👀 But especially not while they’re working from home. At home, your employees will probably:

• Face more distractions (like kids!)
• Step away to put a load of washing on
• Grab a coffee (and probably a few other things 😋🍛🍫🧁) from the kitchen

In between all of that, you need to trust that they’ll get their job done, do their best, and be productive - even if it happens outside of regular business hours.

Fortunately, if you’re agile, you likely have built a culture of trust already. So, keep up with regular communication, virtual standups, and transparency. This should be enough to monitor progress and keep your people accountable without micromanaging

7. Stay social

Even if you can’t meet face-to-face, create opportunities for your teams to come together virtually, socialise, and chat. Set up a non-work Slack channel, do regular video calls, and talk about more than just work. People, relationships, and connectedness matter even more when you can’t be in the same room together.

8. Get better at risk management

When all of this blows over (and it will), you’ll come out a much stronger organization than before. If a single team member, a whole team, or your entire organization need to work remote in the future, you’ll be able to easily switch gears with minimal disruption.

Use this opportunity to uncover risks you might not have considered previously. Ask questions like:

• What if half of us get sick and can’t work for a few weeks?
• What backup options are in place for our internet connection, files, and communications?
• What if our building is suddenly inaccessible?
• Become more aware of potential risks to your company so you can be better prepared in the future.

9. Look on the bright side

While a pandemic isn’t an ideal scenario, it’s okay to look for the positives, like:

• Your teams may find they love working from home
• Some distributed agile teams will find they’re actually more productive
• You'll get greater work/life balance
• No commutes
• More quality time with family
• Reduced emissions from cars and planes
• Quieter roads with fewer traffic jams and accidents

And maybe… just maybe… some of these changes will stick around for the better 🤞

Waste is expensive! 💸 It’s paying someone not do any real work, paying for supplies you don’t need, or paying for team members to sort out a preventable issue. Lean agile aims to eliminate wasteful resources and tasks for improved efficiency and reduced costs — while never sacrificing quality. In fact, lean agile prioritizes bringing value to the customer with every decision that’s made.

Lean agile is a development method that helps teams identify waste and refine processes. It’s a guiding mindset that facilitates efficiency, effectiveness, and continuous improvement.

Consider this: You probably work a lot better when your desk isn’t completely covered with a mess of things you don’t need. When you eliminate distractions and waste, it establishes an organized workspace and workflow. This helps you focus on what’s most important, ensuring you work efficiently and effectively.

Here, you’ll learn more about the development of lean, the benefits of lean agile, and the five core principles of lean.

The development of lean agile

Lean agile, or lean software development, originates from the principles of lean manufacturing. The concept was brought into manufacturing to improve profits by reducing costs instead of solely relying on increased sales. If a company can eliminate waste and become more efficient, it can save money, thereby increasing overall profits.

Lean agile is an agile methodology that, in basic terms, is quite simple: improve efficiency by eliminating waste. Unlike traditional, waterfall project management, which dictates a set plan laid out by a project manager, lean agile strives to reduce all tasks and activities that don’t provide real value. This helps ensure everyone involved in a project or product development can work at optimal efficiency.

If you’re looking to dive into the history of lean agile, Lean Enterprise Institute Inc., founded in 1997 by James P. Womack, PhD, is a leading resource for lean methodology. It aims to help people and teams work better through lean thinking and practices.

Lean practices are popular because they can be applied to other agile approaches and software development methods. Lean agile provides a clear application for scaling agile, which is often difficult for large or growing organizations.

The benefits of lean agile

In case you’re not on board with lean agile yet, let’s review its main benefits.

Waste less time

Time is wasted when processes don’t run smoothly. In lean manufacturing, it’s important for goods and services to be delivered quickly and effectively. No one's time should be wasted on the job, and companies should aim for shorter lead times without sacrificing quality.

Wasting time in any industry is expensive, but it’s particularly important to pay attention when working in agile software development. Even a small bottleneck or broken process can completely throw off a workflow or product deadline. Lean agile helps development teams manage time effectively to ensure everyone is utilized, no one's time is wasted, and roadblocks are anticipated in advance.

Reduce costs

When businesses eliminate waste, they save money. In its original form, lean manufacturing ensured companies had the right amount of materials, employees, and working hours at any given time. Overproduction, overhiring, or simply having too many materials to store are expensive wastes that can be eliminated through better management of systems and processes.

Any business, no matter the industry, will save money with improved efficiency. Lean agile ensures that waste is continually eliminated and agile teams continue to fine-tune processes for optimal efficiency.

Improve work quality

With lean agile, it’s not only about efficiency — it's about maintaining efficient processes while bringing a quality product to customers and stakeholders. When businesses intentionally improve processes, they remain competitive. Lean principles consider the customer value of any action or decision to ensure needs are always met or exceeded.

The five principles of lean agile

There are five core principles for implementing lean methodology:

1. Value
2. Value stream
3. Flow
4. Pull
5. Perfection

These principles describe a five-step process that guides the implementation of lean techniques for manufacturing, software development teams, and other agile practicing industries.

1. Identify value

The first step requires you to step into the shoes of the customer. Value is what the customer needs and wants from a specific project or product.

Consider from the customers’ point of view: What are their expectations? What are they willing to pay for? How do they want their needs met?

Sometimes, customers may be unable to define exactly what they’re looking for — especially if it’s a new product or technology they’re unfamiliar with.

In any case, the project cannot move forward without clearly identifying what it will take to provide customer satisfaction. You’ll need to identify the end goal (value) customers are hoping to find with the product or service.

2. Map the value stream

Next, the team visually maps each of the steps and processes it will take to bring the product from inception to delivery. By making each step visible and always keeping the value top-of-mind, it’s easier to see which steps don’t directly contribute to continuous delivery. Once wasteful steps are found, the team finds ways to eliminate those steps or reduce them as much as possible.

Getting rid of waste ensures your company doesn’t unnecessarily spend money on steps and processes that don’t add value. And — most importantly — the customer gets exactly what they’re looking for.

3. Create flow

Once the waste is eliminated from the value stream, the next step is ensuring the remaining processes work as effectively and efficiently as possible, which means no delays, disruptions, or bottlenecks. It’s important for the steps that create value to work in tight sequences to ensure the product flows smoothly toward the customer.

In order to achieve this kind of agile transformation, lean businesses must train their employees to be adaptive and multi-skilled, create cross-functional teams, break down and reconfigure steps in the production, and balance employee workloads.

4. Establish a pull system

With enhanced flow, your team can deliver products and services faster. A pull system enables “just-in-time” manufacturing and delivery, limiting inventory and work in progress (WIP) items by only producing enough to meet customer demand.

By establishing a pull system, you create products and services as needed as opposed to creating them in advance, which leads to a growing inventory or list of tasks that need to be stored and managed — draining your bottom line.

5. Seek perfection

By completing steps 1-4, waste is eliminated — for now. However, the work is never done. There is always a process that could be improved, and there will always be steps in project and product development that waste time and money or don’t deliver value. That’s why the fifth step of seeking perfection is key.

Lean takes time to implement, and going through the process once is not enough. Build a continuous improvement mindset into your company culture, and never settle for the same old.

Lean agile made easy

Lean prioritizes the elimination of waste to improve efficiency. This helps teams continually improve their processes while emphasizing the tasks that bring the most value to customers.

If you’re looking to learn about how agile principles work with other development approaches, we recently covered eight different software development methodologies, including rapid application development, extreme programming (XP), and other agile frameworks.

Easy Agile is dedicated to helping teams improve their processes and agile methods. Our Jira plugins help product owners, Scrum Masters, and development teams align around product goals, workflows, and customer needs. The tools are simple to use, collaborative, flexible, and they work seamlessly with Scrum, Kanban boards, and other agile processes managed in Jira software.

You can contact our team or watch a demo to learn more about our tools and follow our blog for the latest content on Jira, agile, lean, and the development process.