Agile Teams

We believe there’s a better way for teams to work. That’s why we built a suite of powerful Jira apps. In this post, we’ll share more about Easy Agile Personas, Easy Agile TeamRhythm (formerly User Story Maps), Easy Agile Roadmaps, and Easy Agile Programs. We’ll go over how to use these tools as well as key features that will help your team.

A key principle of working in an agile way is flexibility. It throws away rigid plans and instead embraces an iterative process that evolves with the needs of the customer.

We believe in the power of agile, and we’re passionate about helping teams work better together. To us, that means working with simple tools that are flexible, collaborative, and customer-centric. That's why Easy Agile apps for Jira always keep the customer top of mind. Let's take a deeper look at the plugins that will improve the way your team works in Jira.

Product development with Atlassian Jira Software

Jira cloud solutions take a customer-first approach to designing products. And Atlassian products are commonly used by software development teams.

If you're on an agile team or looking to build your agile capability, a key foundational tool is Atlassian's Jira Software.

With Jira, you can:

• Create Jira workflows to plan, track, and release customer-centric products
• Choose between multiple frameworks, including Kanban, Scrum, or both
• Manage backlogs with complete visibility
• Use structured features designed specifically for sprint planning
• Search for issues and Jira instances with JQL, Jira Query Language
• Improve performance based on real-time data
• Reduce physical dependencies by moving your agile solutions online

Easy Agile Apps for Jira

Jira is an amazing platform with tons of features agile teams can make good use of, but it may not offer the best solution to your specific use case. For specific solutions, such as integrated customer personas or a tool for PI Planning, you’ll need a Jira app from the Atlassian Marketplace, like the Easy Agile tools we’re about to cover.

Easy Agile Personas for Jira

Customer Personas help development teams zero in on a customer-centric approach. They dig deep to understand exactly what customers need and want so that software development teams can deliver on those desires.

Customer personas are vital to understanding how to bring consistent value to clients. They answer questions about customer pain points, behavioral patterns, goals, demographics, buying habits, and more. Effective personas really get to the heart of what makes customers tick so that every software development decision is based on the real people who use the product.

Easy Agile Personas for Jira is designed to produce customer-centric work. It helps teams empathize with customers so they can make development decisions based on what will provide the most value to users.

Our persona tool integrates directly with your current Jira projects. You can create and store customer personas for a smooth experience that prioritizes customer needs every step of the way.

Watch an on-demand demo to learn more. And did we mention our persona template is designed to work with Easy Agile TeamRhythm? You can add personas directly to your TeamRhythm user story map. Our agile plugins are designed to work better together.

Easy Agile TeamRhythm

Backlogs are full of potential, but when you have more than a few items on your list, a flat backlog can quickly become overwhelming. What do you start with first? What fits within the bigger picture? And what’s going to bring the most value to your clients?

Flat maps are bland, void of context, and they provide no insight into the customer journey. It’s like choosing an original Nintendo game when you have a VR headset available. Nice for nostalgia, but not for making stellar products.

Enter the TeamRhythm User Story Map.

Our co-founder, Nicolas Muldoon, describes user story mapping as “a facilitated, curated conversation that brings everyone along for the journey.”

User story mapping is an effective way of organizing and prioritizing your user stories for the purpose of scheduling your work and designing releases. It helps teams visualize the customer’s journey through the creation of your product from start to finish, and it includes all of the tasks to complete along the way.

A user story is a goal or outcome that the user or customer wants to achieve. It’s the smallest unit of work capable of delivering value back to the customer.

Here’s an example of how a user story is typically written: “As a [persona type], I want to [action] so that [benefit].”

It’s your user’s story, so it’s best written from their perspective. Each user story is then added to your backlog, where they can be arranged and prioritized on a user story map according to your scheduled release or sprint. Read our ultimate guide to user story maps to get started.

Easy Agile TeamRhythm is an add-on designed to help teams provide value to customers fast and frequently. Manage and breakdown epics inside the story map, plan core user activities, order stories by priority, edit story summaries, and more — all while integrating seamlessly with your agile boards in Jira.

It’s time to transform your flat product backlog into an impactful and visual representation of the customer journey. Follow our Easy Agile TeamRhythm to see what we’re currently working on and what functionality is coming up next.

Easy Agile Programs Jira plugin

Program Increment (PI) Planning involves intense, focused planning to determine what needs to happen when and how everything connects. It’s when product managers can review the backlog, communicate with stakeholders, and ultimately decide what next steps will bring the most value.

The problem is these planning sessions can get quite complicated, and it’s difficult to track everything on a physical Program Board. Online agile tools help teams consolidate information so they can see the big picture. They prevent lost information, misinformation, poor test management, double handling, and inaccessibility, all while maintaining the visual process of PI Planning.

Easy Agile Programs for Jira is the complete PI Planning solution for agile teams. It’s the most effective way to visualize programs within Jira. Keep all the parts you like from your physical Program Board while increasing automation and getting rid of overwhelming layers of sticky notes and connectors. Plus, with an online tool, you can work as a team remotely while doing PI Planning.

You can plan your Program Increment with digital cards with all the string you need for solving complex problems. Our app connects to Jira dashboards to help you seamlessly manage programs, configure priorities, and streamline visibility. With a Jira PI Planning app, you’ll gain better context, a streamlined workflow, increased collaboration, and improved transparency.

Watch our on-demand demo and follow our Easy Agile Programs roadmap for the latest product updates.

Easy Agile Roadmaps Jira plugin

Product roadmaps are an agile staple. They provide an iterative and collaborative process, so the software development team can continually provide value to customers and stakeholders.

Unlike static Gantt Charts or Excel Sheets, roadmaps are fluid and versatile. They are a living document that represents the team’s hopes at a specific time, based on the current needs of the customer. As needs and demands evolve, so does the roadmap.

Easy Agile Roadmaps for Jira help teams align around a product vision to sequence the most critical features for customer delivery. Our Roadmaps allow teams to add subtask themes, date markers, custom fields, split scheduled work, track progress, and export any roadmap to share with stakeholders.

It’s intuitive and simple to use for everyone on your team from product managers to developers to stakeholders. Easy Agile Roadmaps connect seamlessly with your Jira instance to plan Jira issues directly from the issues panel. It’s the simplest and most flexible roadmapping tool for Jira with one-click drag and drop functionality and a super-clean user experience.

You’ll love visualizing your process, and you’ll love how simple it is to get started. Learn how to create a Jira roadmap using Easy Agile Roadmaps or watch a demo for more information.

Try any Easy Agile Jira plugin free for 30 days

Each of our Easy Agile Jira plugins is available free for 30 days, so you can begin using them without any commitments. If you have any questions don’t hesitate to contact our team.

What is a customer persona?

Customer Personas are fictional generalizations of your most valuable customers.

They help teams understand their customers by bringing together demographic information like age, gender, location, and income, alongside psychographic information like interests, frustrations, and personal or professional motivations.

What are user personas?

Now It might seem trivial at first, to come together as a team, mocking up what seems like fake dating profiles for your most important customers.

However, this exercise sets the foundation for other agile practices down the track, and its benefits are often undervalued.

Agile experts have called for more cross-functional teams, which means this knowledge of who the customer is, is no longer the sole responsibility of your Sales and Marketing team. Everyone is responsible for understanding who the customer is.

Teams that have a shared understanding and alignment around who is actually using the solution they are delivering are more likely to succeed.

Building customer personas helps teams to address the following questions:

• Who are our customers?
• What are their common behavioral patterns?
• What are their shared pain points (professional and personal)?
• What are their goals and objectives?
• What general demographic and psychographic information may influence their decisions?
• What drives them to make purchasing decisions?
• Is the customer the buyer or decision maker?
  

There are two steps you can take to answer these questions and start to identify who your customer personas are:

Firstly, broadly define your personas

It’s not crazy to think that most companies will have some broad idea of who at least some of their customer personas are. This knowledge is accumulated over time and is based on customer feedback, support requests, conversations/interviews, and initial market research.

This knowledge is not to be underestimated and is a great starting point before looking towards analytics to flesh these personas out into more specific detail.

Secondly, look towards insights and analytics

Once you’ve come up with a few customer personas, it’s time to flesh them out with qualitative and quantitative data.

So where can we find this information?

Look at sources like:

• Website Analytics
• Facebook Insights
• Customer Surveys & Polls
• Industry reports
• Customer Interviews or
• In-Product Analytics

After looking through all of this information you can map back the data against your original assumptions.

By the end of the exercise, you and your team should have a pretty good idea of who your customers are, and how to best service them, communicate with them and build solutions for them.

Customer personas in Jira

Once these personas have been developed, the challenge is choosing where to store them.

Making the personas highly visible should encourage your team to consider them each time new work enters the backlog. You want them to think, “What would Sam the System Administrator think about this new feature? Would she use it? How would she communicate its benefits to her team? What are some of the problems Sam may encounter on first use?”

That’s why we created an app for Jira - Easy Agile Personas.

Easy Agile Personas enables you to create and keep your user personas in Jira alongside your work, so the entire team can keep the customer in mind.

Whether you choose to use Easy Agile Personas or not, the customer personas you develop are vital to building user story maps.

Try it now

Sometimes the idea of writing user stories can seem like another "thing" on top of an already busy workload. But for software development teams who are looking to lead their own improvement and deliver software that works for their customers, writing effective user stories is the first step.

If you’re reading this post, it means you want to learn what will work best for the people who use your software, and improve how you approach software development. That's great! Our goal at Easy Agile is to help you do that.

So let’s start with why good user stories are important.

Why write user stories?

You may wonder why you should write user stories rather than writing features or tasks instead.

If this sounds like you, you might not yet have seen the value of writing user stories, and that they serve a very different purpose to writing features or tasks.

It’s easy to get buried in a cycle of feature development that lacks context. The objective becomes more about clearing your way through a large backlog than building solutions that add value for your customers. To build successful software, you need to focus on the needs of the people who will be using it. Your human customers. User stories bring that context and perspective into the development cycle.

What is a user story?

A user story helps agile software development teams to empathize with their customers. Written from the customer (or user) perspective, user stories help the development team understand what they need to build, and why they need to build it.

User stories are simplified, high-level descriptions of a user’s requirements written from that end user’s perspective. A user story is not a contextless feature, written in “dev” speak.

A User Story = the 'what'

A user story describes a piece of functionality from the point of view of the user.

User stories divide features into business processes.

A task = the 'how'

Tasks are the activities that need to be performed to deliver an outcome.

Tasks are individual pieces of work.

How do we write user stories?

You might like to think of a user story as an ‘equation’:

As a [user] + I want [intent] + so that [value]

Let’s break this down further;

As a [user] — this is the WHO. Who are we building this for? Who is the user?

I want [intention] — this is the WHAT. What are we building? What is the intent?

So that [value] — this is the WHY. Why are we building it? What is the value for the customer?

Let’s look at a few simple examples;

As an internet banking customer

I want to see a rolling balance for my everyday accounts

So that I can keep track of my spending after each transaction is applied

OR

As an administrator

I want to be able to create other administrators for certain projects

So that I can delegate tasks more efficiently

Following this equation, teams should make sure that their user stories are ticking all of the following checkboxes:

To write successful user stories:

• Keep them short
• Keep them simple
• Write from the perspective of the user
• Make the value or benefit of the story clear
• Describe one piece of functionality
• Write user stories as a team
• Use acceptance criteria to show an MVP.

Acceptance Criteria

User stories allow agile teams to balance the needs, wants and values of their customers with the activities they need to accomplish to provide that value.

The link pairing these two things together is acceptance criteria.

Acceptance Criteria or ‘conditions of satisfaction’, provide a detailed scope of user requirements. They help the team understand the value of the user story and help the team know when they can consider something to be done.

Acceptance Criteria Goals

Acceptance criteria should:

• clarify what the team should build before they start work
• ensure a common understanding of the problem or needs of the customer
• help team members know when the story is complete
• help verify the story via automated tests.

Let’s look at an example of a completed user story with acceptance criteria:

As a potential conference attendee, I want to be able to register for the conference online, so that registration is simple and paperless.

Acceptance Criteria:

• Conference Attendance Form
• A user cannot submit a form without filling out all of the mandatory fields (First Name, Last Name, Company Name, Email Address, Position Title, Billing Information)
• Information from the form is stored in the registration database
• Protection against spam is working
• Payment can be made via Paypal, Debit, or Credit Card
• An acknowledgment email is sent to the attendee after submitting the form

With this in mind, teams should make sure that their acceptance criteria considers all of the following:

• Negative scenarios of the functionality
• Functional and non-functional use cases
• Performance concerns and guidelines
• What the system or feature intends to do
• End-to-user flow
• The impact of a user story on other features
• UX concerns

Acceptance criteria should NOT include the following:

• Code review was done
• Non-blocker or major issues
• Performance testing performed
• Acceptance and functional testing done
  

Why?

Your acceptance criteria should not include any of the above, because your team should already have a clear understanding of what your Definition of Done (DoD) includes, for instance:

• unit/integrated testing
• ready for acceptance test
• deployed on demo server
• releasable

Writing effective user stories is a valuable practice that will help you and your team deliver software that stays relevant for your customers.

When you embrace user stories as more than just another task on your checklist, but instead view them as an essential tool for creating context and value for your projects, you can stay connected with your ultimate focus - your customer.

Transform your backlog into a meaningful picture of work to gain context for sprint and version planning, backlog refinement, and user story mapping.

Stay focused on your customers

Easy Agile TeamRhythm

Creating a product roadmap in Jira can fulfill a few really important roles.

1. It can establish a vision for an agile team struggling for momentum.
2. It can communicate to the broader business what you’re planning to work on in future iterations or sprints.
3. It can help the product manager visually record dependencies between issues.

Bonus: by creating a Jira roadmap you won’t need to track down that one you created in Google Sheets or PowerPoint (or did I create it as a table in Confluence?) 🤷

Sorted. Sold. Show me how!

Ok — this is how you can create a free roadmap in Jira using Easy Agile Roadmaps:

Step 1. Go to the Atlassian Marketplace

Hop over to the Atlassian Marketplace page for Easy Agile Roadmaps.

Step 2. Start and install free 30 day evaluation

Press the yellow ‘Try now’ button to start your 30 day free evaluation. This means you can create a full roadmap and impress your team before you decide if it’s right for you.

You’ll need admin rights on your Jira to start a free evaluation. Or buy coffee for someone who does.

Choose from Cloud, Server or Data Center (whichever Jira hosting type your company uses).

Step 3. Open the roadmap

Once Easy Agile Roadmaps is installed, each Scrum and Kanban board in Jira will have a linked roadmap.

To open it up, look for the Roadmaps icon found in the Project Sidebar for all agile boards on Jira Server and for single-project agile boards on Jira Cloud.

If you’re on a multi-project agile board on Jira Cloud, the roadmap link can be found in the ‘…’ dropdown on the top right of your agile board screen.

Step 4. Add your first item to the Jira roadmap

Your blank roadmap should now be staring at you. ✅

You can add any issue type to a team’s roadmap. To access the issues from a team’s agile board, select the blue button marked either “Issues” or “Epics” in the top right of the roadmap.

Select the ‘Options’ dropdown to check the issue types you would like to appear in your roadmap backlog.

Then, drag and drop onto the roadmap. You can adjust the start and end dates and phasing of each issue by dragging the left or right ends of the coloured boxes.

If you’d like to send your roadmap to someone who doesn’t use Jira, you can export it as a PDF.

Congratulations! You just created a product roadmap in Jira. Now you can show it off to your team and delete your excel roadmaps FOREVER.

There’s a ton of other features that comes with Easy Agile Roadmaps, like Themes, Version Markers and Date Markers.

We’ll cover that in a future post. You can try out all of these in the free 30 day evaluation.

But for now, bask in the glory of your new roadmap.

Sit back and marvel at what you have created. You deserve it.

Try roadmapping today with Easy Agile Roadmaps for Jira

👉 👉 Read next: Principles of an Agile Product Roadmap

Raise your hand if you've ever had an argument, oops 😳 — I mean a heated discussion — on how to set up and organize Jira. Yeah, us too.

Some hotly contested topics include:

• Project: Is it best to organize by team, by function, by feature, or by product?
• Agile epics, features, stories, tasks, sub-tasks, bugs — what should you use and when?
• Sprint board column headings and swimlanes — we're not even going there.

Unfortunately, there isn't one best workflow in Jira or any tool your agile team uses. More important than your workflow is setting up your team members to consistently deliver business value to your end-users. The goal of your agile project management is to enable and support your Scrum team in this endeavor.

We're going to take a look at one aspect of your process — through the epics agile teams use. Stick with us, and we'll explain what an epic is, why agile epics are important, and how to avoid some epic mistakes.

What is an epic?

Simply put, an epic is a bucket that holds smaller work items that must be completed to satisfy the task. Some people think of epics as a big user story. That's fine if it helps you visualize it, but epics are quite different from stories.

• Agile teams use epics differently for planning or not at all.
  While your team might be able to give it a t-shirt size, the amount of work in an epic is usually too large to be estimated in story points. Some epics are so large that they need to be broken down into smaller epics before you even ask for team estimates.
• An epic isn't written like a user story.
  You know the template — “As a user, I want to X so that I can Y.” That’s perfect for a user story, but not so much for an epic. An epic example might be "Add cross-sells" with a description that lists places where the Product Owner would like to present the end-user with opportunities to purchase related products. That’s not a story, but a request for functionality.
• The epic might be acting as a placeholder for work that is yet to be defined.
  Your Product Owner may use epics as placeholders on a product roadmap for long-term planning. They'll wait to define the work until the implementation time frame is closer.
• An epic is rarely completed in a single sprint.
  Because of their size, epics typically don't fit within one iteration. Your software development team slices functionality so they can deliver working software each sprint. This may mean they complete a story or two from an epic for two sprints, skip a sprint, and then go back to stories in that epic the next sprint.
• Epics may or may not have acceptance criteria.
  Some Scrum teams don't require epics to have acceptance criteria because it's included in the stories. If all the child stories meet what the Scrum defines as the Definition of Done, the epic is also Done.

Epics are parents and grandparents to stories and tasks. Development teams don't work on epics but rather code to the smaller user stories under the epic.

The importance of epics in your agile practice

Don't underestimate the organizational value epics bring to your product backlog. Corralling 10 or 20 related backlog items can be disruptive in sprint planning. Epics present a more cohesive look at the work and allow your Scrum team to see the big picture.

Epics offer executives and product managers a high-level overview of work in progress and what’s coming in the future.

Product Owners use epics to create a product plan from a business perspective. Current business goals may dictate that development work is focused on a particular feature represented by epics. By contrast, epics also help Product Owners plan sprints with an appropriate work ratio from multiple epics. Product Owners can take a step back from the detailed user stories and make sure each iteration contains stories from several epics to satisfy multiple stakeholders.

The way epics are visually represented in product backlogs and roadmaps is critical for long-term planning. Can you imagine planning a six-month roadmap at the user story level? It would be chaos!

Agile frameworks encourage — no — demand the ability to adjust course as needed to meet changing stakeholder needs, market demands, and business goals. Epics allow you to easily and quickly adapt your roadmaps in response to change.

How epics add value to agile development

Discovery is a big aspect of agile methodologies and product management. At the beginning of this process, your teams will be event storming, creating personas, and building journey maps. The actionable output of those activities is easily logged and organized in Jira with epics.

As those epics are further refined, they're added to a roadmap and then put on a Refinement ceremony agenda. During Refinement, the Scrum team members engage in user story mapping exercises and begin to build the detail needed for the development team to execute.

While epics provide a less detailed view of features and requests from your Product Owner, they are critical to the creation of user stories. Without the cohesive view of your sprint backlog presented through epics, agile sprints are at risk of delivering a lot of unrelated work that delivers little value.

When not to use an epic

So, while we love the agile epic, it's not perfect for everything. Here are some things to avoid when using epics.

The evergreen epic

You know the one. The epic was created when people stopped using wired telephone lines and has been lingering in your backlog in a semi-complete state ever since. Deep within, you'll find user stories and tasks, maybe with little or no relation to each other. This poor epic has become the dumping ground for orphaned stories that didn't find a home anywhere else.

Evergreen epics can be the result of a change in either business goals or product features. That’s great — you've adapted! Now you need to update your epic to reflect that. Stories can be removed, code can be deployed or shelved, and incomplete stories can be deleted or removed from the epic and reprioritized.

Brainstorming is also a cause for evergreen epics. Above, we mentioned that output from UX activities is a great way to manage actionable items. We did not say to use epics as a home for every idea that came up during brainstorming that may or may not ever make it to your roadmap.

Epics are not intended to live forever. They represent a body of work that will deliver value to your end-users and need to be completed so you can measure the results of your efforts. Evergreen epics clutter your roadmap, blurring your focus, and limiting its planning value.

The theme epic

It's easy to assign stories to epics because they're related to a specific area in the product, touch a certain code base, or satisfy an individual or group of stakeholders. That's not the purpose of an epic. Themes are a better choice for grouping work by attributes other than a specific feature implementation.

You can accomplish your organizational goals by using themes to link these stories while maintaining the integrity of scope within your epic.

Use epics to focus on specific deliverables or features. Related or not, if a story within an epic doesn't contribute to the primary focus of the epic, remove it. That doesn't mean it's not important or the right work to do during the iteration. It just means it's not part of that epic.

Being diligent about epic scope keeps your estimates cleaner and more useful for future planning. Unnecessary stories in epics inflate their estimates and actual efforts. If you ever need to look back at older work items, you probably won't remember that adding two unrelated stories was what bumped an epic from a medium to a large. If you’re using that old work item as a guide for future planning, you’ve just overestimated the effort because you didn’t limit the scope to the objective of the epic.

Keep in mind — not every story needs an epic parent. Some stories stand well on their own and might be better visualized and planned through themes.

The release epic

A release is not an epic. A release is a specific set of code and files that are bundled together and delivered to production at the same time. A release may include an epic or many epics, or it may not. But in itself, a release is not an epic.

There are excellent tools on the market developed specifically to help you with release management. By all means, assign your epics to a release, but use release tools to organize your releases and use epics to organize your features.

Epics are more than a large user story

Your agile coach or Scrum Master has probably drilled you on the Principles of Agile Software, so you know the following quote from the 12 Principles of Agile Software:

"Simplicity — the art of maximizing the amount
of work not done — is essential."

But what does it have to do with epics?

Epics simplify your backlog. They allow you to focus on the right things at the right time and keep out the noise. They keep your eye on the ball when it comes to prioritizing value and ignoring the ankle-biter work in your backlog.

We believe using epics makes for better organization in your backlog and better planning for your agile teams. Epics help you deliver value sooner by keeping you focused on the big picture and out of the weeds.

If you want a more contextual view of your epics and user stories in Jira, try Easy Agile TeamRhythm. The highly-visual story map format transforms the flat Jira backlog into a meaningful picture of work, making it easier to manage your backlog and plan sprints or versions.

DevOps vs. agile—what’s the difference? These two methodologies have a lot in common, but there are also many key differences that we’ll discuss in this post. You might say they compliment each other. We wouldn't go so as far as to say they’re like peanut butter and jelly, but when used together, they certainly make for a nice combination.

In basic terms, it comes down to this: Agile solves the gap that can exist between end users and developers, whereas DevOps solves the gap that can exist between developers and operations.

Sound simple enough? Well, there’s a lot more to it than that. Let’s dig a little deeper into the definition of both agile and DevOps, what these methodologies have in common, what makes them different, and how they can work together.

Defining agile

The agile methodology was first popularized in software development, but in recent years, agile practices as well as the guiding principles of agile have expanded into a range of different industries that want to prioritize continuous improvement and growth.

The agile approach to project management is much different than the traditional approach to project management. Traditional project management follows a waterfall model. Each project element must be completed before moving on to the next in a strict sequential order, and the flow of work remains the same from project to project.

Agile focuses on flexibility, adaptability, collaboration between team members, and delivering consistent value to stakeholders through continuous customer feedback and rapid releases. Each iteration offers fresh insights into what is and isn’t working and what could be improved upon. It’s a multidimensional approach that eliminates the bottlenecks so characteristic of traditional project management.

Agile teams can implement agile in a variety of different ways, including Scrum, kanban, lean, and more. A key benefit of agile software development is the ability to bridge the gap between customers or users and development teams.

Learn more about agile, dig into the Agile Manifesto, and read our article: Agile 101: A Beginner's Guide to Agile Methodology.

Defining DevOps

DevOps is a software development method that empowers teams to build, test, and release software quickly and consistently with the integration of agile practices and principles, including enhanced automation and improved communication and collaboration between development and operations teams.

DevOps focuses on aligning development and IT operations to better manage end-to-end engineering processes. In the past, development teams would write applications and then pass them along to an operations team that would then deploy and manage the software. The problem with this approach is the operations team is given no insight into how the application was developed.

DevOps practices bridge the gap between developers who develop and write the software and operations who run the software.

➡️ Learn more about other popular software development methodologies.

DevOps vs. agile: What do they have in common?

Both agile and DevOps aim to aid the software development process, but where did they come from, and what commonalities do they share?

In this “which came first, the chicken or egg?” scenario, we do actually know which came first. 🐓🥚 Agile, which gained popularity in the early 2000s, provided development teams with an approach to solving complex problems. While agile solved many problems, there was one disconnect that remained — the operations teams deploying the software were sidelined and remained in a silo, missing out on the benefits of agile.

Enter DevOps, which applies agile principles to improve the gap that often exists between development and operations teams. It offers operations teams visibility into the development process so that they can better understand how and why a product was made. This clarity aids the development process since both sets of teams can work alongside one another while developing and deploying.

The result is development practices that run smoothly from one team to the next, a heightened consideration of the user, and continuous delivery to both customers and stakeholders.

So, in many ways, DevOps is an extension of the original agile methodology. DevOps teams  zero in on a key aspect of the development process to bring development and operations together. Many of the same agile principles are applied, such as continuous deployment, improved collaboration, iteration, and automation, and implementing feedback at every turn.

Key differences between DevOps vs. agile

While agile and DevOps have a lot in common, there are a few key differences to be aware of. The differences mainly stem from the different types of teams utilizing agile principles. These different teams have different needs, work at a different pace, and are guided by separate feedback systems.

AgileDevOpsAgile is a broad methodology that focuses on solving complex problems and bridging the gap between development teams and product/project management through improved communication and collaboration, continuous iterative development, stakeholder feedback, and frequent releases. DevOps takes agile one step further, focusing on bridging the gap between development and operations teams to better manage end-to-end engineering processes. Agile can be applied to any industry that wants to emphasize continuous improvement, collaboration, and communication. DevOps is mostly used within software development.There are many different frameworks that can be utilized to implement agile, including Scrum, kanban, lean, and XP (eXtreme Programming).DevOps is an agile framework that exists because of agile.Agile focuses on iterative development and working in small batches.DevOps emphasizes constant testing and delivery automation. Agile development is typically managed through sprints: 2-4 weeks time in which a set amount of work is completed and submitted to stakeholders for feedback.The goal of DevOps is to deliver code to production as frequently as possible, either every day or every few hours. Feedback comes from stakeholders, customers, and users.Feedback comes from the internal team. Agile uses the Shift Left testing approach (testing early and often to get the code right the first time, reducing the time it takes to get the product to market).DevOps uses both Shift Left and Shift Right testing to get the code right the first time and to understand and optimize the software’s functionality and usability in real-world situations, enabling wider test coverage.

Bridging every gap in the development process

Let’s bring it all back to the simple definition we began with. Although there are many complexities, similarities, and differences between DevOps vs. agile, in basic terms, it comes down to this:

Agile, which came before DevOps, is a broad methodology that primarily focuses on bridging the gap between the customer/user and development teams. DevOps, which came second, utilizes agile practices to fill the void that remains between development teams and operations teams.

Easy Agile is dedicated to helping all types of teams work better using various agile methodologies. We design agile apps for Jira with simple, collaborative, and flexible functionality. From team agility with Easy Agile TeamRhythm, to scaled agility with Easy Agile Programs, our apps can help your agile teams work better together, and deliver for your customers.

Book a 1:1 demo

By now, you’re pretty familiar with Scrum. It’s given your team a framework they can work with to achieve internal goals so they can deliver quality software to customers. But, you can always improve your Scrum practices to continue to delight your customers. 😁 One of these is the daily scrum — a practice that sounds straightforward, but is easy to mismanage (more on this soon 😉).

The daily scrum consists of three elements — Scrum roles, Scrum artifacts, and Scrum events.

In this article, we'll show you how these components fit into the all-important daily scrum meeting, provide some tips to keep your daily scrum running smoothly, and discuss what traps to avoid so that your team is always on task. We'll also point you towards resources that will get you proficient in the other elements of agile. Our goal, as always, is to make you an agile pro. 🏄🏽‍♀️

What is the Daily Scrum Meeting?

Let's do a quick recap of each of them before we dive into the daily scrum:

• Scrum roles: These are the product owner, the Scrum master, and the development team. These Scrum team members work together as a unit to achieve their goals.
• Scrum artifacts: Artifacts include the product backlog, the sprint backlog, and the increment. The artifacts represent information to the team that enables them to have transparent views against which to measure their progress.
• Scrum events: The sprint, sprint planning, daily scrum, sprint review, and sprint retrospective give the team an opportunity to meet and refine any of the Scrum artifacts that need adjusting to keep the team's goals within view.

The daily scrum is a meeting between team members to discuss its current sprint progress. It's time to discover if any adjustments to the sprint or the product backlog need to be made in order to achieve its sprint goal.

Importance of Daily Scrum

The daily scrum plays a crucial role in enhancing both team coordination and communication. This brief, focused meeting offers the team a structured environment to align on progress and obstacles, contributing to several key areas:

1. Progress Transparency: Team members get a clear view of what everyone is working on, which fosters accountability and mutual support.
2. Impediment Identification: Problems and potential roadblocks are surfaced early, allowing the team to address them promptly and minimize project delays.
3. Focused Collaboration: By keeping discussions relevant and on-point, the team can spend their time more effectively, concentrating on solutions rather than prolonged debates.
4. Goal Alignment: The meeting helps reaffirm and refocus efforts toward the sprint goals, ensuring everyone is aligned and moving in the same direction.

By adhering to best practices, such as keeping the meeting time-boxed and promoting an inclusive atmosphere, teams can maximize the benefits of the daily scrum, leading to a more cohesive and efficient working environment.

Key Participants in the Daily Scrum

Development team

The development team members are the main participants in the daily scrum. During the meeting, they report on their progress towards the sprint goal to discover if any adjustments need to be made. They can do this by each answering three questions:

1. What did I work on yesterday towards the sprint goal?
2. How do I plan on working towards the sprint goal today?
3. ​Is there anything preventing me from finishing what I am working on?

By doing so, everyone on the team is in the loop of the full team's progress. The answers to these questions also allow the team to uncover any blockers and adjust the sprint backlog accordingly. An example of a blocker may be a bug that prevents one developer from finishing her assigned user story in the sprint.

Scrum master and product owner

In traditional Scrum, the Scrum master and product owner aren’t active participants — and aren’t technically required — in the daily scrum meeting since they don’t do the development work that will achieve the sprint goal. However, they can still be valuable meeting participants. It’s up to the Scrum team to decide if they should attend.

• The product owner can lead the way in adjusting the sprint's backlog items. For example, the bug that is blocking other work can be moved so it gets fixed in time to keep the sprint goal within reach.
• The Scrum master can make sure that daily scrum best practices are being followed and that the team is avoiding some of the common pitfalls that betray the objectives of the daily scrum meeting. Let's look at those next.

What's the Difference Between Daily Scrum and Daily Standup?

Sometimes, it can be confusing to tell the differences between daily scrum and daily standup — and sometimes the terms are used interchangeably. However, it's worth pointing out the differences between the two.

A daily scrum is an event that is defined in the Scrum guide. So, then what is daily stand-up, and how is it different? 🤔

A daily stand-up is a daily meeting whose objective is to provide team members with progress towards a common goal. However, it is less restrictive in terms of its participants and time limits. In other words, team members outside of the Scrum team can participate and the meeting can run longer than 15 minutes. For example, a company may conduct a daily stand-up that includes its entire staff or a particular department whose progress updates are not limited to the development of software.

Daily Scrum Best Practices

So, what are the best practices for conducting your daily scrum meetings effectively?

1. Complete the daily scrum in a time box

A 15-minute time frame is most commonly used to ensure that the team stays focused and on point. After all, team members only need to answer their three questions succinctly and effectively.

2. Conduct the meeting at the same time and place every day

This will provide a level of consistency and regularity and will help foster the Scrum values of commitment and focus.

3. Include the same team members in each daily scrum meeting

If you have a rotating cast of characters, then you run the risk of disruptions. Some people in the meeting will likely be missing context from prior meetings and will need to be updated.

Daily Scrums for Remote or Distributed Teams

Daily scrums are pivotal in ensuring team alignment, but for remote or distributed teams, they require thoughtful execution to maintain effectiveness. Here's how you can make the most of your virtual daily scrums:

Leverage Video Meetings Intelligently

Video meetings bring the advantage of live conversation, crucial for real-time collaboration and clarity.

• Respect Personal Needs: Recognize that being on camera can be draining. Offer flexibility by allowing team members to choose when to use their cameras.
• Avoid Fatigue: Encourage camera use for important discussions but provide options for audio-only participation to prevent exhaustion.

Manage Time Zones Wisely

Distributed teams often span multiple time zones. Here's how to navigate the challenge:

• Schedule Smartly: Find a suitable meeting time that works for the majority. For instance, someone might join in the mid-morning while it’s early morning for others.
• Consider Asynchronous Updates: When time zones are vastly different, rely on asynchronous communication like task board comments or chat channels to keep everyone informed without disrupting their work-life balance.

Utilize Visual Tools

Visual aids can significantly enhance understanding and engagement in virtual meetings.

• Screen Sharing: Use screen sharing to display task boards or project management software, providing a clear, visual context for discussions.
• Collaborative Tools: Leverage tools like Miro or Trello for visual brainstorming and task tracking during the scrum.

Define Working Agreements

Creating clear working agreements ensures everyone is on the same page regarding processes and expectations.

• Communication Methods: Specify how team members should communicate, whether through video calls, messaging apps, or emails.
• Collaboration Tools: Decide on which tools to use for documentation, real-time collaboration, and async updates. Popular options include Slack for communication and Jira for task management.

Daily Scrum Pitfalls

There are tempting activities to avoid while conducting your daily scrum meeting. These are some of the common pitfalls to avoid:

1. Using the meeting as a status update

To the product owner, Scrum master, or other stakeholders. The main objective of this meeting is for the development team to answer their three questions so that they can make any needed adjustments to keep the sprint goal intact. It should not be used as a status meeting for developers to report on the progress of their work.

2. Turning it into a problem-solving session

To resolve any blocks that are discussed in the meeting within the 15-minute time frame. One thing will undoubtedly happen if the team attempts this — the meeting will run too long! The Scrum master should advise the team to stay on task during the meeting and defer these problem-solving attempts to time outside of the daily scrum meeting.

3. Focusing on a task board

As a means of tracking progress. The daily scrum meeting is a time for discussion. If the team is staring at a task board, it's wasting valuable time by focusing on the status of tasks and not on talking about making adjustments to its work.

In addition to these key points, there are several other common mistakes that can derail the effectiveness of a daily scrum:

• It’s become a boring status meeting that no one wants to attend. This indicates a lack of engagement and purpose.
• Developers are reporting personal performance to a scrum master or manager, which can undermine the collaborative spirit of the team.
• The meeting isn’t held if the scrum master can’t make it that day. This dependency can disrupt the consistency of daily progress checks.
• The team is trying to solve problems and find solutions during the daily scrum, which should be avoided to respect the timebox.
• The daily scrum is being used to refine work items, which is not its intended purpose. Refinement should occur separately.
• The timebox isn’t respected, leading some team members to feel like the meeting is a burden. It's crucial to stick to the 15-minute limit.
• Some developers think they don’t need to show up, which can result in misalignment and missed opportunities for team synchronization.

By being aware of these common pitfalls and maintaining a focused and efficient daily scrum, teams can ensure they are making the most of their time together and keeping their sprint goals on track.

Master Daily Scrum and Become an Agile Pro

At Easy Agile, we provide products to manage all of your Scrum events. We are passionate about making agile accessible and easy to understand for its participants. In addition to our products, we love to provide resources so you can level up your agile game 💪. Check out our blog and our podcast to become an agile pro!

Being agile vs doing agile – what’s the difference?

Organizations around the world have recognized the need to respond rapidly to meet the challenges of constant change. As a result, they’re racing to adopt agile ways of working, with the pandemic accelerating agile adoption.

Those who get it right can make a powerful impact on their bottom line and their competitive edge. But for others, the benefits may yet to be seen.

This is where ‘doing agile’ versus ‘being agile’ can make all the difference. Because to truly reap the benefits of agile methodology, organizations need to shift from doing to being.

This article will explain the difference between being agile vs doing agile. Plus, we’ll take you through some of the common challenges many organizations face in their agile journey.

Key points

• To realize the full potential of agile ways of working, teams must cultivate an agile mindset as well as adopt agile processes.
• Moving from ‘doing agile’ to ‘being agile’ takes time, coaching, and a new approach to management.
• Done right, being agile can amplify customer satisfaction, employee engagement, growth, and profitability.

Why agile, and why now?

Agile had already been rising in popularity for over 20 years, but once the pandemic hit, this growth accelerated.

Across every industry, being able to deliver digital experiences is now crucial. Organizations now need to act and think like software companies, with a laser focus on the customer’s online experience. Together with an active approach to finding customers, you need to deliver real value to stand out from competitors.

For organizations looking to survive - and thrive - in this environment, many are turning to agile frameworks to rapidly add customer value and drive business results. Being agile allows teams to:

• Make the complex simple – by working within a clear, structured framework, chaos turns to order.
• Maintain a clear overview – agile teams have a shared understanding of their progress towards their goals.
• Replicate success – if a team finds an effective way to deliver results, they can repurpose and share solutions across the organization.
• Create an aligned, purposeful culture – when hundreds of people across one organization form dozens of agile teams, they build a stable backbone, walking the same path towards the same goal.

"Agile organizations, viewed as living systems, have evolved to thrive in an unpredictable, rapidly changing environment. These organizations are both stable and dynamic. They focus on customers, fluidly adapt to environmental changes, and are open, inclusive, and nonhierarchical; they evolve continually and embrace uncertainty and ambiguity. Such organizations, we believe, are far better equiped than traditional ones for future."

- McKinsey & Company

What does it mean to be agile?

Many organizations incorporate a few agile processes to manage projects. But that doesn’t mean teams have fully understood and embraced the agile methodology. It could be that they’re ‘doing agile’ rather than actually ‘being agile’.

Here’s the difference between the two:

Doing agile

‘Doing agile’ is the misconception that if you do agile things your company will become agile and responsive to change. Organizations that have fallen into this trap may go through the motions of some agile processes, such as daily stand-ups, sprints, and retrospectives. Teams are structured to be small, cross-functional, and collaborative. But by stopping there, those teams don’t become truly agile and they may struggle to see results.

While agile ceremonies, tools, and structures are critical in implementation, they are only part of what makes an organization agile.

Being agile

‘Being agile’ means you incorporate the above activities but go beyond the processes. This means applying an agile mindset and agile values to all areas of the organization. Teams will need training to master the agile mindset and push through any challenges along the way. It takes more time and effort than simply doing agile, but it’s critical if you want to reap the benefits.

What’s an agile mindset?

Embracing an agile mindset means understanding and living its four core values. To be agile, you need to:

1. Respect people - Recognize that people are critical to the success of your organization. Ensure people share common goals, feel safe and empowered to share ideas, and adopt a ‘we’ versus ‘I’ mentality.
2. Optimize flow - Build in quality at each increment so you can identify issues and course-correct early. This helps maximize value and minimize waste while creating a consistent, sustainable flow of work.
3. Encourage innovation - Foster experimentation with collaboration, constructive feedback, and autonomy. Schedule time and space for creativity and ideas to flow.
4. Relentlessly improve - Keep in mind that there is no endpoint with the agile mindset. It’s about continuous improvement, so you need to continually reflect and improve future processes as part of an ongoing practice.

To take these values and make them the foundation of working across your organization, you need to combine agile processes with an agile mindset. Without the agile mindset, you’re not ‘being agile’, and your processes won’t deliver your organization’s full potential.

"The agile mindset is a thought process that involves undersatdning, collaborating, learning, and staying flexible to achieve high-performing results. By combining the agile mindset with processes and tools, team can adapt to change and deliver incremental value to their customers."

- Atlassian

Agile processes and tools aren’t enough

Agile processes, including the ceremonies, tools, and apps, are there to support the mindset of the team. But without getting the mindset right across your organization, you won’t be truly agile.

Fostering the agile mindset gives an organization the ability to rapidly move in any given direction at any given time to deliver the best value to customers. Teams who’ve mastered agile are usually:

• Autonomous and empowered to make decisions around the product and customer experience.
• Able to adapt to change quickly.
• Always willing to learn something new.

Engaged with a shared purpose and collaborative culture.

"It's about being able to pivot to change. Whether that's in terms of people, or resources or budget - whatever that looks like for an organization. If you're able to quickly shift from one area of focus to another before your competitor does, then you have a competitive advantage in the market."

- Sean Blake, Head of Marketing, Easy Agile

Common challenges to look out for as you move from doing agile to being agile

The sooner you can act and move from doing agile towards being agile, the sooner your customers, employees, and your bottom line will benefit.

Here are a few common challenges and tips to overcome them.

• People might hold onto old habits
  People find change hard, especially when habits are ingrained. You might find some people dig their heels in, clinging to the old way of doing things. It’s important to remember it can take time, and people will need support to learn new ways of working. Be sure to bring in plenty of opportunities for feedback and discussion so you can reiterate as a team to find a process that works for your organization.
• It’s not just the team who needs to be coached
  Being agile is a mindset for the entire organization, including managers and executives. If your leaders don’t understand and support agile, it will be hard to get traction and shift old processes and hierarchies. Scrum Masters and Agile Coaches need to spend time coaching leaders to develop new agile mindsets and capabilities.
• For many organizations, being agile requires a new style of management
  The traditional command-and-control management style may have worked in the industrial age. But now it’s a mismatch for the way organizations and people need to work today, and it doesn’t support the agile mindset. To be agile, teams need the trust, autonomy, and ability to take an idea through to execution without any roadblocks. Senior executives must get behind this multifaceted cultural-transformation effort for this to happen.

Are you ready to be agile?

Moving beyond agile processes to scale an agile mindset across an organization isn’t something you can tackle overnight. It takes time, effort, training, and leadership support to internalize agile values and move beyond the command mindset of the past.

You may face challenges along the way, you’ll discover there’s always more to learn, and you must be agile in your adoption of agile.

But the prize for true agility is significant, including increasing customer satisfaction, boosting employee engagement, and improving productivity - making it well worth the investment.

Agility helps modern organizations thrive through change in an uncertain and unpredictable world. For most of us, it’s no longer a desirable way of working - it’s essential.

If one thing is certain in product development (or in life), it’s that time is always passing, and there are always tasks to be completed. There’s no more straightforward way to calculate both of these critical metrics than a simple burndown chart.

Burndown charts help agile teams visualize time vs. task completion, which means the amount of work left compared to the amount of time planned in the development of a product or a specific sprint.

In this post, we’ll explain what burndown charts are, the benefits of using them, and how they are used by development teams. We’ll also explain the difference between burndown vs. burnup charts, product burndown charts vs. sprint burndown charts, and share helpful tools for integrating critical metrics in Jira. Now let’s slide down that y-axis!

What is a burndown chart?

A burndown chart is a visualization of how much work is left to do and how much time there is to complete it. Visible to everyone, this graphical representation predicts how much work the team plans to complete within the allotted time. Burndown charts are also used to measure how quickly an agile team is moving through and completing customer user stories. They are excellent for keeping the team aware of any scope creep.

Let’s look at what each part of the graph represents. The amount of work remaining is shown on the vertical axis. The time that has passed since starting the project or sprint is displayed on the horizontal axis. So, the x-axis is the timeline of the project or iteration, and the y-axis is the work that needs to be completed.

The total amount of work to be done on the project is at the top of the y-axis on the left, and the endpoint on the far right of the x-axis represents the final day of the project or specific iteration. The start and endpoints are connected by the ideal work line, a straight line that shows what the team hopes to accomplish within a predetermined time frame. Another line, the actual work line, shows the amount of work that remains and how quickly the team is actually performing.

Actual work line vs. ideal work line

A burndown chart shows both the actual work line and the ideal work line. Both lines begin at the start point at the top of the y-axis. As the project or iteration goes on, the actual work line will oscillate around the ideal work line, depending on how the team is progressing.

If the team stays on schedule, the actual work line won’t deviate much from the ideal work line and remain decently straight. If the team hits a lot of time-sucking roadblocks during the project or sprint, the actual work line will be more of a wild squiggle, and it may not reach the x-axis endpoint before time is up.

The benefits of using burndown charts

Burndown charts are helpful in a few key ways. These charts:

• Provide a visual representation of the progression of work completed over time.
• Keep product owners informed of development progress for a product or specific sprint.
• Keep the whole development team on the same page about how far along a product is.
• Are regularly updated as work is completed and as time passes to show product progress in real-time.
• Provide advance notice if a product is not progressing fast enough.
• Capture clear metrics that can be reviewed during retrospectives.

Burndown chart vs. burnup chart

A burndown chart tracks how much work remains by starting at the tip of the y-axis and tracking downward toward where the endpoint meets the x-axis as time goes on and work is completed.

A burnup chart does the opposite. The start point is at the bottom corner of the graph to the left most of the x-axis. A burnup chart’s ideal work line and actual work line track upward as work is completed and time passes. Toward the top of the y-axis is another horizontal line representing the scope of the project, such as the number of story points needed to complete. If the scope becomes larger, say if story points or sprint backlog items are added, the scope line rises to account for the elevated goal.

If the scope of a sprint or project changes due to unexpected developments or stakeholder insight, which is bound to happen over the course of development, these changes are represented by the scope line. This can make burnup charts a slightly more adaptable tool.

Both burndown and burnup charts track a team’s velocity, workflow, and progress. A burnup chart’s scope line takes into account the evolving nature of software development and how the goalposts can move over the course of a project, which makes them ideal for tracking a project as a whole. While they are both effective tools, a burndown chart could be better utilized during a sprint because the number of tasks in a sprint is less likely to change.

Product burndown vs. sprint burndown chart

There are two different kinds of burndown charts. A product burndown chart shows how much work remains for the entire project, whereas a sprint burndown chart shows how much work remains in a specific iteration.

A product burndown chart collects a larger amount of data. It represents everything that needs to be completed on a product during the specific time requirement agreed upon at the beginning of the project.

A sprint burndown chart helps Scrum masters visualize how fast the agile team gets the work done and how much work is left to do during a sprint. It shows the Scrum team’s progress by displaying how much work actually remains instead of time spent. Over the course of a sprint, the chart will slope downward across the completed story points.

If the burndown line on a sprint burndown chart is not tracking downwards by the time you reach the middle of the sprint, it’s a sign that the sprint is not going well, and it’s up to the Scrum master to get the team back on track.

Working on your next product plan? Learn about common agile planning mistakes and how your team can avoid these common pitfalls.

Burndown charts in Jira

Broken Build’s Agile Reports and Gadgets include burndown and burnup charts for both Scrum and Kanban.

The application is designed for Jira, so you can integrate reporting in real-time. Having access to immediate metrics helps teams spot bottlenecks and dependencies, so they can be addressed sooner rather than later. The application lets you export charts and customizable reports to share with team members and stakeholders or to review during retrospectives.

How Easy Agile can help your team

We’re passionate about helping agile teams work more efficiently and effectively while always putting the needs of the customer first. We create products specifically designed for Jira users, including Easy Agile TeamRhythm, Programs, Personas, and Roadmaps.

Try Easy Agile TeamRhythm to build simple and collaborative story maps in Jira. Our tool will help you transform your product backlogs into an impactful visual representation of the customer journey. It’s the highest-rated story mapping app for Jira, trusted by over 120,000 users at companies like Amazon, Twitter, Starbucks, Rolex, and Adobe.

Product development without an agile workflow would be like building a house without a blueprint or defined roles on the construction team. No one knows what to do or who does what. 🤔

The result: time and energy wasted building a single house that would most likely reveal its darkest flaws over the years.

So, here’s what you need to know: Process increases efficiency. It also increases efficacy, customer satisfaction, and a better experience for the team members who take a part in the process.

Follow this how-to guide to building and implementing an agile workflow in Jira. In this article, we’ll cover what an agile workflow is and define the steps for its creation and its principles in depth.

The notion of workflow

The execution of a team's work is dictated by one or more processes. In other words, a process is a way the team gets to the finish line with deliverables. And if you're developing products with an agile framework, an agile workflow is a way to structure that process.

Generally, a workflow is made out of:

• Activities, tasks, and steps
• Roles
• Work products
• A few other things to help improve team collaboration and work execution

With such a structure, it gets easier:

• To repeat the process
• For team members to work with each other
• To scale the process and the work itself

It seems like a workflow is so well-organized that teamwork would flow smoothly just because it exists. Well, that's not the case. In the next section, you'll learn that there's not a workflow for any team or project. Instead, there are one or more workflows that work for your team or your project.

Why there's no one-size-fits-all workflow

The size and maturity of teams have an impact on their workflows. Also, the type of project and both company culture and team culture influence the configuration of workflows. Bottom line: Your agile workflow will depend on many factors, and it’ll likely be unique.

You might, however, find online suggestions of workflows that prove to work with other companies. So, if you prefer, you might use those as a starting point for the definition of your own workflow. It might be the case that excluding some steps does the trick for you. On the other hand, you might define your own workflow from scratch.

Jira is a very versatile solution for workflow management that supports many different agile workflows.

With Jira, you may customize workflows to different company cultures or team cultures. In this context, culture means the way team members work with each other. In the same vein, a workflow expresses the dynamics of a team in one or more projects.

Now, if we're talking about Jira workflows, you should know what one of those contains.

What's a Jira workflow exactly?

A Jira workflow is an agile workflow built on top of and implemented with the help of Jira. It's a digital board that allows checking the statuses of work items. It may also send notifications when those items change status. You can also use your Jira board for Scrum meetings such as daily standups and sprint retrospectives.

You absolutely need to keep the statuses of ALL work items accurate. That means updating the status of each work item whenever and as soon as it changes.

Only an up-to-date agile workflow — and Jira board — fulfills its purpose and delivers benefit. It's an awesome tool for team members, Product Owners, and Scrum Masters to track work progress at all times.

Let's move on to our guide now. You'll find out, one tip at a time, how to become an agile workflow rockstar with the help of Jira.

Your guide for agile workflow in Jira

Start your engines! You're heading on a fabulous learning journey about the creation and management of agile workflows in Jira. Here are our best tips to make this process happen:

1. Start now

Don't postpone getting your hands dirty with workflow definition.

Even if you start simple, just get started. Don't delude yourself into thinking that you'll succeed at agile if you start big. In fact, that could work against you and your project.

2. Don't overwork

Don't spend weeks structuring, restructuring, and then restructuring your workflow some more.

Overworked workflows are hard to understand and much harder to implement and comply with. That would harm the basic principles of agile methodology.

With an overloaded workflow, you'd end with team members not knowing what to do and when to do it. Consequently, at the end of the sprint — or iteration — and project, no deliverables would be ready to roll out.

3. Don't forget about workflow stakeholders

You should account for roles that will somehow use the workflow you're defining. Whereas some will use it daily to get work done, others will use it only for some kind of management analysis.

You should understand with them what their workflow needs are. It'll take time, so you must be patient.

4. Understand the concept of ‘issue’ in Jira

In project management, an issue describes a problem for which there's no solution yet. Those issues come from risks to the project's development process and ultimate success. For instance, adding a functionality to the project scope — the issue — could come from the possibility of requirement changes — the risk.

However, in Jira, an issue doesn't necessarily represent a problem. Rather, it represents a piece of work that teams must complete. For instance, a Jira issue can be a task or a helpdesk ticket.

With software development, a Jira issue may symbolize more specific concepts such as:

• Product features and functionality that the development team must implement
• Bugs that must be solved

5. Know the pieces of the puzzle

In Jira, a workflow has four types of components:

1. Status. This indicates the position of an issue in the workflow. It can be an open — or unresolved — status or a closed — or resolved — status.
2. Transition. This defines how an issue changes status, and it can be either uni or bidirectional. You can create more or fewer constraints depending on how statuses change. You can even define that only certain people or certain roles can change an issue from one specific status to another.
3. Assignee. This is the person responsible for an issue.
4. Resolution. This describes why an issue went from open to closed statuses. Additionally, it should only stick to an issue while it’s resolved.

In software teams or projects, it's common to find statuses such as:

• "To Do" for issues yet to start
• "In Progress" for issues that the team already started to tackle
• "Code Review" for completed coding tasks that need a review
• "Quality Assurance" for completed issues that require testing by a team of testers
• "Done" for completed, reviewed, and tested work

When a code review is successful, the work is done. In this example, the code review's success is a transition from the status "Code Review" to the status "Done." And the resolution would be the reason why the code review failed.

Finally, you can set up transitions with:

• Conditions. They prevent an inadequate role from changing the status of an issue.
• Validators. These ensure a transition only occurs under certain circumstances. If not, the transition doesn't happen.
• Post functions. They describe actions on issues besides changing their status, and you can automate them. For instance, remove the resolution from a resolved issue before changing its status back to unresolved. Another example would be to remove the assignee from that issue.
• Properties. These are characteristics of transitions. For example, one characteristic could be to only show resolutions relevant to the type of issue.

6. Define ‘done’

Every team is unique. It’s made up of different people, different habits, and different experiences with technology and methods. Different ways of getting work done. This means you need to define what “work done” means to your team or your project.

For instance, you need to answer the following questions for your team or project:

• What status should a product or a feature have when it’s approved to launch or release?
• What should your team members do to get each work product to that status?
• Who should make decisions — such as approvals — along the way, which decisions, and at which points?
• Who declares work as done?

7. Customize Jira default workflow

Remember that you could use Jira to customize workflows to different ways of working as a team? Here’s how to do it:

Step #1: Define your workflow's statuses and transitions in Jira workflow designer.

You may go with Jira default Scrum or Kanban workflow — Jira classic templates — or make some changes to it. Alternatively, you may choose the Jira simplified Scrum workflow, which is adequate for reasonably basic requirements.

The simplified version of the Scrum workflow contains:

• Three statuses: "To Do", "In Progress", and "Done"
• Two transitions: from "To Do" to "In Progress" and from "In Progress" to "Done"
• Four columns to organize issues distributed across boards: "Backlog," "Selected for Development," "In Progress," and "Done"

Step #2: Build your workflow by adding components to the simplified Scrum workflow.

To track issue progress in agile development, you might add statuses such as "Code Review" and "Quality Assurance." And, you might add a validator to the transition from "Code Review" to "Done" to force that you need a successful code review to mark “Done.”

In addition, you might include approval stages in the workflow such as "Awaiting QA." These stages are prior to those in which an issue is closed or changes to a closed status.

Step #3: Nail the visual presentation of the diagram.

Once you finish tailoring the workflow to your team or project, make sure that the diagram is visually readable. That's essential when sharing the diagram with stakeholders for feedback. You should collect feedback from at least one representative of each kind of stakeholder.

An interesting feature of Jira is the workflow lets you give visual highlight of issues. This lets you see where the issue is in the workflow according to its status. Just open the issue and click on the "View Workflow" button next to the issue's status.

8. Rely on Jira reports for progress tracking

Jira provides two useful reports for tracking the team's work progress on a sprint:

• The Burndown Chart, which shows:
• The amount of work left to do in a sprint
• The work that team members are executing at the moment
• The distribution of work throughout the sprint
• Whether issues fit into the sprint and the effort estimation was adequate
  
• The Sprint Report, which includes:
• The Burndown Chart
• A list of open and closed issues for that sprint
• Extra work added to the sprint

As with any other report, Jira reports allow you to reason about success and failure. In this case, it's the success and failure of each sprint in terms of:

• Effort estimation
• Team performance
• Process irregularities
• Sprint planning

Most importantly, you can use Jira reports for the continuous improvement of those aspects and preventing problems such as:

• Too much work for a sprint
• Rushing work
• Sudden changes in priorities

A Jira workflow comes in handy when detecting outliers in the development process such as:

• A large number of open issues
• Frequent issue reopening
• A high number of unplanned issues added to the sprint

Being able to detect these problems is extremely valuable in that it helps avoid a massive sprint failure.

9. Share information

People at your company who aren't members of your team might need information from your workflow. So, take that into consideration when defining your team or project's workflow.

Those people might need to know about:

• The amount of completed work
• The product backlog dimension when compared to team performance
• The number of open and closed issues or the number of issues in a specific status
• The average issue completion time
• The average number of issues that take too long or experience bottlenecks, which means not moving forward at specific statuses such as "Quality Assurance"

10. Keep it simple

⚠️It can be tempting to create issue statuses while moving issues through the workflow, but don't do it! Each additional status adds more transitions and all their customized characteristics.

❌If your workflow already allows you to assess the sprint and feed your stakeholders with valuable information, that's just perfect. You don't need to add more issue statuses to it.

✔️Add extra issue statuses only when you have no other option. For instance, when different teams need to track work in different stages of development, you might need different statuses.

11. Limit work in progress

You may determine a specific limit to the number of issues in a specific status. When doing so, you should make sure all the team has enough work at each workflow status.

Plus, you should ensure that the limits you introduce into the workflow don't exceed the team's capacity. If you don't, the team will need to prioritize and you may not want that to happen.

Team performance should increase if you set the right work-in-progress limits. 🤗

12. Prepare to scale up

Agile teams should be small. Nevertheless, an agile workflow should cope with an increase in the number of people working with it. This means no one should notice if an increase takes place.

Here are some golden rules for scaling agile workflows:

• Agree on agile practices for workflow definition and minimize customization when multiple teams working on their own projects must collaborate.
• Different teams working on the same project should use the same workflow, or things could get messy.
• Teams should compromise when defining a common workflow. However, that's when teams build workflows based on multiple past successful experiences.

What else can you do?

Whenever you hear about workflows, it’s a sign that the work’s execution is being structured. It's also a sign of a long way ahead, but the outcome will be awesome if you:

• Follow the 12 rules above
• Choose a flexible issue tracker in terms of workflow customization, such as Jira
• Complement the issue tracker with the right apps

Don't force your team or project to comply with a tool. 😨 Rather, do the exact opposite! Choose the tool that allows you to build and implement the right workflow for your context.

That will increase throughput and workflow compliance levels, which is exactly what you want when creating a workflow.

Keep your agile approach strong — streamline, discuss, and iterate. These are the keywords for building and implementing an agile workflow, so don't forget them for a single second! As a result, you'll avoid:

• Complicating the workflow when it's not absolutely necessary
• Disregarding the pains of stakeholders and team members have when using or viewing the workflow
• Having an outdated workflow that's no longer adequate for both the company culture and the team culture

Kick your agile workflow up a notch

Easy Agile TeamRhythm helps you build and implement a Scrum workflow in Jira. Optimize your agile workflow by:

• Visualizing what the team will deliver and when by arranging user stories into sprint swimlanes
• Prioritizing user stories in each sprint by ordering them inside the respective sprint swimlane
• Reviewing sprint statistics at a glance to ensure that the team's capacity isn't exceeded
• Registering effort estimation in user stories.

Story points in agile is a microcosm of agile development itself — working together as a team to estimate scope develops an atmosphere of collaboration, shared understanding, and continuous improvement. Agile story points can also provide clarity in a user story map by providing insights into how much effort you're planning to allocate to developing each part of your customer's journey through your product.

Story points are effort estimators. They’re an alternative to traditional estimation techniques that measure the expected effort of a project in days, weeks, or months. With agile story points, instead of asking, "How long will this project take?" we use relative estimates about the effort it might take to complete each item in the backlog. For example, an item that is assigned two story points is expected to be twice the effort as an item estimated as one point.

So, why should agile teams use story points? Let's see how story point estimation, sprint retrospectives, and velocity metrics all build consensus and allow team members a clear vision into the prioritization of your product backlog.

Story point estimation for the whole team 🙌

In sprint planning, product and engineering teams work in tandem to gain a shared understanding of the effort required to complete backlog items. During planning, the team agrees to a story point estimate for each user story in the sprint.

Point estimation is a practice in collaboration and consensus-building among team members. The team as a whole participates in determining the point value for each item in the sprint. By discussing each other's perspective on the estimates:

• Product owners better understand developers’ reasoning for their estimates.
• Developers gain empathy for the product owner's need to assess tradeoffs and make prioritization decisions from sprint to sprint.
• QA testers have an opportunity to weigh in on the complexity and risk of the work being estimated and the amount of work needed to create and run tests.

One common methodology for employing agile story points is to assign values to backlog items using the Fibonacci sequence — 1, 2, 3, 5, 8, 13, 21...you get it. Mike Cohn provides a succinct reason for this approach — numbers that are too close to each other are difficult to differentiate. This sequence of points provides a much better jumping-off point for your team to discuss the relative effort of backlog items than a liner point system (i.e., 1, 2, 3, 4, 5...you still get it).

By planning with agile story points, you avoid the temptation to place artificial deadlines on sprint items. It's also easier to reach a consensus on the relative scope of items compared to attempting to place a timeframe on each item. You'll spend less time planning and more time working on your sprint!

Estimates are...estimates

Guess what? Your estimates don't need to be perfect! The process of agile estimation is difficult but provides software development teams an opportunity to feel comfortable with story point estimates being just accurate enough to continuously develop. Over time, you will learn from each other and will improve at creating better estimates.

Unpredictability exists in every project. By using rough estimates that are relative to each other, you avoid the trap of overplanning and allow developers to get to work. Story point estimates allow teams to build smooth planning cadences and move seamlessly from one sprint to the next.

Sprint velocity and other key metrics 📈

Agile story points enable another valuable tool for teams to continuously improve their estimation process — metrics. Several metrics can be used in the context of story points and estimation, but we'll focus on two of the most popular ones — burndown and velocity.

Sprint burndown

In any sprint iteration, the team commits to the amount of work that they believe they can complete in that timeframe. A burndown chart visualizes how the team is progressing relative to its commitment over the course of the sprint.

The y-axis is the number of points in the sprint, and the x-axis displays time in the sprint. There are two lines in the chart. The ideal work remaining line connects the start date of the sprint to its end date (it crosses the x-axis to indicate all of the sprint's work is done). The actual work remaining line shows what still needs to be done. The overall idea is for this line to track the ideal line as closely as possible, meaning your estimates are sound and you are completing the sprint's work at a nice pace.

When reviewing this chart, you’ll find common problems facing agile teams. Here are some examples:

• Over- or under-committing to an amount of work
• Adding points to the sprint after it's already started
• Erratic movement in the actual work remaining line
• Overcommitments that force user stories into the next sprint

Burndown is closely related to velocity, which measures your team's pace of work.

Sprint velocity

A development team's velocity is the amount of work that is completed in each sprint. It can be used as a measure of how long it will take the team to work through its backlog. Because agile story points are as a relative estimation, teams can use them as a baseline to understand how their velocity evolves.

Here, we see a representation of a team's velocity over the course of several sprints.

Sprint retrospectives are an opportunity to discuss any issues made apparent by the sprint's burndown or the team's velocity. It's a time to reflect as a team, review your metrics, and figure out if there are opportunities to refine your process and improve together.

Here are some questions to ask during this process:

• Should we adjust our expectations of getting through the backlog?
• Do we need to tweak our estimation process?
• Should we consider adding a team member?
• Are we over- or under-committing to the amount of work in our sprints?

While these metrics provide insight into your estimation process and your team's pace of getting through your backlog, putting your items into a user story map provides another layer of context on your overall prioritization decisions.

User story mapping with agile story points

Story points are not only important in the context of sprints. Placing them in user story maps produces a visual of strategic product prioritization.

User story mapping in a nutshell 🥜

A user story map takes the items in your flat backlog and places them in the context of your user journey through your product. It's a view of all of the actions your customers take from sign-up to log-out and every major action they take in-between. Instead of having a straight list of items (backlog), the user story map organizes them by your customer's workflow.

For a more comprehensive view of this method, read our ultimate guide to user story maps.

Unflatten your Jira backlog with user story maps

With Easy Agile User Story Maps for Jira, you can see the number of agile story points assigned to each stage of your users' story map. Seeing point estimations in your customer’s journey provides product teams and stakeholders a user-focused view of prioritization.

This can help answer questions such as:

• Are we investing too much effort into one part of the journey?
• Should we smooth out the allocation of points across the journey or focus on one key problem area?
• Will the next release provide enough added value to our customers at a certain stage in their product journey?

It also provides another chance for your team to collaborate! By reviewing your story map together, you're sure to come up with more insights and iterate on your prioritization decisions.

Agile story points, combined with user story mapping, is an effective way to bring teams together to create an agreed-upon view of prioritization across a customer’s journey.

A common misunderstanding with agile software development methodologies is that they don't follow a formal process. Each team just does their own thing with little or no planning, and somehow it all works out. Well, we hate to burst your bubble, but software development doesn't work like that, agile or not. 🤯

Just like with traditional waterfall projects, agile projects follow an agile software development life cycle (SDLC). From a process perspective, the primary difference is a linear approach with waterfall and an iterative approach with agile. We'll get into this a little more later.

First, let's walk through how an agile SDLC aligns with agile principles. Then we’ll talk about the agile SDLC in both Scrum and Kanban environments.

How the agile software development life cycle supports agile principles

The Agile Manifesto states four basic values that drive improvement in software development processes. They are:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan.

Those are great values! Now raise your hand if you remember the next sentence. Anyone?? Let us refresh your memory: "That is, while there is value in the items on the right, we value the items on the left more."

Too often, new agile software development teams are so excited to start "doing agile" they forget to fully comprehend the entire contents of the Agile Manifesto. We get it — it's hard to remember all 68 words when you're excited. 🤓

So let's take a look at that again: The items on the right have value. That doesn't sound like you should eliminate all documentation, processes, and tools. You actually need some of those things to function efficiently as a team. At the very least, you’ll need to negotiate some type of contract if you're building software for an external stakeholder and you want to get paid.

We'd love to be able to tell you exactly how many processes and how much documentation and planning you'll need, but we can't. Part of being agile is figuring things out as you go along based on your team environment and customer needs. As your agile team matures, you'll begin to inspect and adapt the processes, tools, and project documentation your team needs to work efficiently and effectively.

Now let’s look at a couple of agile software development life cycle models.

The Scrum SDLC model

Remember earlier we talked about waterfall being linear and agile being iterative? Scrum is the perfect agile framework to highlight the difference.

The traditional waterfall model of product development requires several steps before you arrive at a final product. Waterfall projects meet the Definition of Done only after the entire project is complete and in the hands of the user or stakeholder. It's linear — a straight path from start to finish.

The agile method of Scrum, on the other hand, is iterative and adaptive. Scrum teams break the deliverables into smaller pieces with shorter time frames called sprints. The intent is to deliver slices of working software with each iteration throughout the entire product development process.

Rather than a single sprint, as shown above, a full Scrum life cycle looks more like this:

For each iteration, the team plans, develops, reviews, and deploys updates to the product functionality. As stakeholders perform acceptance testing and see the working product, they may ask for new priorities or requirements. That feedback is added to the product backlog to be prioritized with other features and work by the product owner. Then, the process starts again.

Since software is always evolving, this process repeats until the product has either matured to a maintenance level or has reached the end of its useful life and is retired.

Particularly for Scrum, planning is a huge part of the SDLC. Sprint planning brings the team together to prioritize work based on the sprint goal defined by the Product Owner. The daily standup gives the team a chance to coordinate their activities for the day. The sprint review allows the Product Owner and other stakeholders to inspect and discuss deliverables produced during the sprint. And, finally, the sprint retrospective creates the opportunity for the team to reflect on the process, team dynamics, and potential improvements for future.

Smoother Sprint Planning with

Easy Agile User Story Maps

Try Now

Backlog refinement is also a type of planning recommended to be completed prior to a sprint planning session or at the end of a sprint. During refinement, teams can discuss the feasibility of specific functionalities or ideas for development methods to meet the acceptance criteria. They can also plan around resource availability. For example, they might consider creating extra unit tests to reduce the efforts of a tester who will be on vacation part of the next sprint.

The difference between planning in Scrum and waterfall is how much work you plan and when. Waterfall plans the entire project at the beginning. Scrum planning happens all through the development of the product, from the beginning to the end.

The Kanban agile methodology

A Kanban framework has a little different agile process. Work items aren't necessarily related to or dependent on each other. Individual team members can work asynchronously to push new code to production as soon as it's ready. Yet, Kanban is still iterative in that work items are prioritized in a backlog, and then they are developed, reviewed, and pushed to production.

New backlog items are added to the board based on the end-user feedback. The prioritization of work items is regularly reviewed and adjusted, aligning perfectly with the agile value of responding to change.

A big difference with Kanban is that instead of committing to work based on story points and team velocity, each column in the Kanban board can only hold a limited number of work items (WIP limits). This helps teams stay focused, identify bottlenecks in their process, learn where automation might be helpful, and generally understand where their process is working and where it needs a little help.

With Kanban, there is more focus on the continuous flow of work through each stage. The WIP limits help teams identify specific stages that are impeding the workflow so they can figure out the cause, fix it, and ultimately become more efficient. .

Each Kanban team can choose the columns on their board to suit their needs. The goal of Kanban is to improve the speed of work progressing through the board. Close monitoring and measuring work item movement is critical to Kanban teams.

Working with the agile software development life cycle

Whether you're working in a mature company or a startup team, there's value in an appropriate amount of documentation, tools, and process in agile software development methods. In fact, establishing an agile software development life cycle will help your team operate efficiently.

TIP! Looking for more team alignment? Try Easy Agile Programs

Remember to refer back to the Agile Manifesto and The 12 Principles Behind the Agile Manifesto if you get stuck. These values and principles don't apply only to what you're building but also to how your team works. The key concept behind agile frameworks is to inspect and adapt — including both the software and how you’re functioning as a team.

Use as much process and documentation as you need, but no more. Look at what you have today and identify key items you don’t think the team can function without. Then add or eliminate steps as you discover the best way for your team to work in an agile framework.

At Easy Agile, we're here to help you get the most out of your agile practices and to help you grow into a high-performance, agile team. 💪 If you want to learn more, check out our other blog articles on agile topics.

If you need help with Atlassian's Jira tool, we've got some great apps for you to try. Our Easy Agile Programs for Jira app can help your planning activities through alignment at scale and visualising dependencies.

Try Now