Agile Teams

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

How do you feel when someone mentions “planning”? Do you look forward to the opportunity or does the thought of making a plan send you running for the hills?

Sprint planning is a crucial part of the agile sprint cycle. It helps you and your team align around common goals, and sets you up for a successful sprint. Even if planning isn’t one of your strengths, the good news is that you can practice and get better over time with the help of some good advice.

We’ve combined our best sprint planning tips into an ultimate guide to agile sprint planning, with everything you need to run efficient and effective planning meetings.

What is agile sprint planning?

Agile sprint planning is a key ceremony in the agile sprint cycle. It signifies and prepares the team for the start of the sprint. Without this planning, there is a very real risk that the team would lack focus and fail to align on what is most important.

Effective agile sprint planning has three key parts; a sprint goal, an understanding of team capacity, and a prioritized set of backlog items. Each element depends on the other for success.

The idea is to align your team around a goal for the next sprint by agreeing on a set of backlog items that are achievable within the sprint and contribute to reaching the sprint goal. Gaining focus and clarity on what you plan to achieve will help your team to work better together and to deliver on objectives.

It is best to start with an agreed sprint goal. You can then prioritize work on the specific set of backlog items that your team has the capacity to complete, and that will contribute to making your sprint goal a reality.

How sprint planning fits within the Scrum process

We’re big fans of the Scrum process, and it’s hugely popular with many software development teams. While agile sprint planning can take many forms within the different agile methodologies, for the purposes of this guide, we’ll focus on agile sprint planning within the Scrum framework.

If your team doesn’t follow Scrum don’t worry — you’ll still find value in our preparation tips, meeting guide, mistakes to avoid, and sprint planning resources.

💡 Learn more: What's the Difference Between Kanban vs. Scrum?

Scrum roles: The people

There are three main roles within a Scrum team.

1. Product Owner
2. Scrum Master
3. Development team

The Product Owner puts in the work upfront. They help prioritize the product backlog items and decide which should move to the sprint backlog. These important decisions guide the goals of the sprint and determine the tasks the team will tackle over the next sprint.

The Scrum Master acts as a guide, they lead meetings that help ensure that the Scrum framework is followed throughout the sprint to keep the team on track. The Scrum Master helps the team get the most out of the entire Scrum process and each individual Scrum ceremony.

The development team is made up of the various people who will complete the work agreed upon during sprint planning.

There are others that you might refer to during sprint planning, such as stakeholders, users, and customers. While these aren’t technically Scrum roles, they play a critical role in product development. Stakeholders should be brought into the process early and often, and customers should always be top-of-mind when making any development decisions. Some teams find User Personas to be a valuable way of keeping user value in focus.

Artifacts: What gets done

Artifacts are the things to get done — different breakdowns of what the team hopes to accomplish:

1. Product backlog
2. Sprint backlog
3. Increments

Product backlog items are the tasks the team believes they need to accomplish in order to complete a product or specific improvement of a product. It is the big master list of everything that the team thinks they need to accomplish. The product backlog is flexible and iterative, and it will evolve as the team learns more about the product, stakeholder feedback, and customer needs.

The sprint backlog is more focused than the product backlog. The product owner moves the most important backlog items from the product backlog to the sprint backlog at the beginning of each sprint based on current issues, priorities, and customer needs. The team aims to complete all of the sprint backlog items over the course of the sprint.

An increment is a concrete stepping stone toward reaching the Product Goal. An increment must be verified as usable in order to provide value, which means that any work completed cannot be considered part of an increment unless it meets the Definition of Done (an agreement among the team of what “done” means). This is a formal description of the state of the increment when it meets the quality standards required of a product. Once the work completed satisfies the agreed Definition of Done, you gain an increment.

Scrum ceremonies: Where Sprint Planning fits

There are a number of ceremonies in Scrum that occur each sprint. This is where sprint planning fits within the Scrum process.

1. Sprint planning
2. Daily scrum (or standup)
3. Sprint review
4. Sprint retrospective

💡 Learn more: Agile Ceremonies: Your Guide to the Four Stages

Sprint planning is the first Scrum ceremony — it prepares the team for the sprint. The planning session sets everything into motion, aligning the team on what’s most important for this sprint. This is when decisions are made and key backlog items are moved from the product backlog to the sprint backlog.

The second ceremony repeats every day of the sprint. Daily standups bring the team together to discuss progress and blockers that might be getting in the way. By getting the concerns out in the open early, the team can avoid the frustration of delays and ensure work continues to flow.

The final two ceremonies happen at the end of the sprint. For the sprint review, the team comes together to determine the success of the sprint based on the “Done” work completed. It’s also a chance to bring in stakeholders to gather feedback on what's been accomplished so far. The sprint review ensures customer insights are always top-of-mind, stakeholders continually see progress, and guarantees the product never strays too far from what the stakeholders are looking for.

The sprint retrospective gathers critical insights from team members about how the sprint went. What went well, what didn’t go so well, and what could be improved upon for next time? These valuable insights are what makes Scrum agile — the team is always thinking critically about the process and looking for ways to improve the work and how they work together.

We’ll talk about these ceremonies in more detail below when we discuss what happens after the sprint planning meeting.

The benefits of agile sprint planning

Agile sprint planning is a powerful meeting that should not be overlooked or underestimated. It is an opportunity to:

• Bring the whole team together and align around common goals
• Set context by starting the sprint with clear priorities
• Identify potential roadblocks before they occur
• Bring stakeholder feedback into the planning process
• Learn from previous sprints by considering sprint review and retrospective insights
• Consider team capacity and adjust accordingly to ensure that goals are achievable and that the team isn’t overcommitted in the upcoming sprint
• Account and plan for dependencies that may impact the flow of work.

How to prepare for a sprint planning meeting

We know we said that a sprint begins with sprint planning, but there are actually a few important steps you must take in order to prepare for the planning session. Unfortunately, you do need to do a little planning for the planning meeting.

Backlog refinement

Backlog grooming or refinement keeps your backlog healthy, up-to-date, and ready for sprint planning. A refined backlog will help ensure your team’s planning time is used efficiently and effectively since you won't have to waste time adding details to the backlog that could have been completed in advance before everyone came together.

The product manager should groom the backlog a few days before the sprint planning meeting to make sure it’s ready.

Tips for maintaining a healthy backlog:

• Ensure stories are in order of priority
• Prioritize items that bring the customer the most value
• Add detail to the highest-priority backlog items
• Split any user stories that are too big
• Delete any user stories that aren’t relevant anymore
• Create new user stories based on new or clearer needs
• Add items based on new stakeholder feedback
• Make adjustments based on bug fixes
• Assign more accurate estimates

💡 Learn more: Essential Checklist for Effective Backlog Refinement (and What To Avoid)

Be consistent

A consistent meeting time that’s scheduled well in advance will ensure that the entire Scrum team keeps the time slot open. Book your sprint planning meeting on the same day and at the same time every sprint so that no one forgets or double books.

Sprint planning is not a meeting to be shuffled around, delayed, or ignored — sprint planning meetings are essential to the success of every sprint. Ask your team about a specific, recurring time to meet, and ensure it works for everyone.

How to run a sprint planning meeting

While the agile method is flexible and collaborative, it isn’t chaotic; everything needs to begin with a plan.

1. Stick to a set sprint planning meeting duration

As with any kind of meeting, the team can be easily sidetracked without a timebox. After all, talking about the work that needs to be completed is often easier than actually completing it. It’s the Scrum Master’s job to keep the team on track and make sure the time limit isn’t exceeded.

Go into the sprint planning meeting well-prepared; a clear agenda and a well-refined backlog mean your team can get straight to planning.

Set a realistic timebox for the meeting and stick to it. We recommend that you avoid scheduling more than 2-3 hours for a sprint planning meeting, but as you become more skilled in sprint planning, you’ll better understand the length of time that works for you and your team.

2. Use estimates to make realistic decisions

You want your team to be as productive as possible, but overloading them can actually hinder productivity and focus. Unreasonable expectations are demotivating and overcommitted team members are more likely to make mistakes.

You need to understand the effort and time it will take to complete the goals you set out to accomplish for each sprint. Agile estimation techniques and story points provide a better understanding of team capacity, individual capacity, and what a reasonable workload looks like. Reasonable and realistic goals will help your team stay motivated and support a consistent flow of work.

3. Define clear goals and outcomes

What does the team aim to accomplish between now and the end of the sprint? Set clearly defined goals and outcomes that everyone understands. Do your goals align with what you learned from past sprints? Do they align with customer needs? Does everyone agree on what the next sprint will (roughly) look like?

Don’t assume that everyone is on the same page. Ask questions and encourage your team to speak up if anything is unclear. It’s better to clear up discrepancies or misunderstandings now rather than once the work begins.

Post your sprint goal somewhere that is easily accessible so that the team can refer back to it throughout the sprint.

💡 Learn more: How to Make the Most of Your Sprint Goals

4. Decide what it means to be ‘done’

What does “done” mean for any given backlog item, increment, product issue, or product as a whole? The team and your stakeholders need to agree on what done looks like in order to set realistic goals that meet the expectations of everyone involved.

As you set goals and choose which backlog items to complete for the next sprint, be clear about what it means to meet and complete the goals you want to accomplish.

5. Align sprint goals with product goals

Sprint goals should always align with your broader product goals. Your sprint may take a specific direction depending on current product issues, bug fixes, or customer concerns, but it’s important to keep an eye on the big picture.

Choose backlog items with care — make sure they relate to the larger product goal and that each works in sync to move development forward. Overlooking product goals in sprint planning could mean that each sprint looks more like a random selection of to-do lists that don’t connect back to customer needs, relate to product goals, or help you reach important increments. The result will feel like a lack of progress, which risks disengaging the team and other important stakeholders, like your users.

What happens next?

Now that the planning is done, you’re ready to implement your plan and complete the work. But that doesn’t mean that team members go off and work in isolation.

Daily scrum (or stand-up)

The daily scrum or stand-up is an opportunity for a collaborative agile team to maintain progress. It should be a quick check-in at the start of each day.

The team will discuss what has been done in the past 24 hours, any roadblocks they might have hit, and what the team hopes to accomplish the next day.

This critical check-in helps the team stay on the same page, helps to ensure the continued flow of work, and keeps the team on track to achieve sprint goals.

Sprint review

A sprint review meeting takes place at the end of a sprint. It's a chance for the team to review all of the “Done” issues for that period. The sprint review determines whether or not the goal for the sprint was achieved.

It’s a chance to demonstrate shippable working product increments to the team, and also an opportunity to bring in stakeholder feedback. This feedback gives you valuable insights to assess if you’re on the right track, or need to make changes in the next sprint. The sprint review is also excellent preparation for the next backlog grooming and sprint planning session.

💡 Learn more: Introduction to Sprint Reviews

Sprint retrospective

While the sprint review looks at what was accomplished and how to move forward, the retrospective examines your processes and how the team is working together.

What did you learn during the previous sprint? While retrospectives can take many forms, the goal is to discover what worked well, what didn't go so well, and what could be improved upon next time. Your team will use the insights gathered in the retrospective to improve how you work together and deliver value to customers in the future.

💡 Learn more: 5 Steps to Holding Effective Sprint Retrospectives

Agile sprint planning mistakes

It’s easy to fall into bad habits, especially as deadlines and product launch dates approach. Avoid these common agile planning mistakes to ensure your team is always making the most of the agile methodology and the Scrum process.

Unrealistic expectations

Choosing unattainable goals sets your whole team up for failure. Failing to meet your sprint goals sprint after sprint is damaging for team motivation and morale.

Use estimates to set reasonable goals as best you can. Consider team capacity, factoring in your past knowledge of how long tasks take to complete, how the team works, and potential roadblocks that could arise along the way.

Lack of context

Your team will benefit from an understanding of how the issues they’re working on fit into the bigger picture.

Depending on the tool you’re using to plan and manage your work, it can be difficult to see the contextual detail needed to plan and work with clarity. The more items you have, the more difficult and overwhelming it will be to organize and prioritize. Use tools that allow you to add context, depth, and customer insights with clean functionality to adapt your plan to the needs of your team and stakeholders.

Neglecting your backlog

We mentioned this point when we talked about what you need to do to prepare for sprint planning. It’s worth mentioning again because it’s a common mistake.

When you go into a sprint planning meeting without a well-managed backlog, you lack the clarity you need to plan effectively. Your time is valuable, and so is the time of your team, so it should be treated with care and used effectively.

A well-managed backlog is DEEP:

• Detailed appropriately
• Estimated
• Emergent
• Prioritized

💡 Learn more: The 4 Characteristics of a Good Product Backlog

Not allowing the plan to adapt

When you plan your sprint, you’ll do everything you can to prioritize the most important tasks for the length of the sprint. It’s important to try to stick to the plan as best you can, but you also need to adapt as you acquire new information.

Be ready to make changes on the fly should you hit roadblocks or acquire new information about customer needs, concerns, or product issues.

Failing to understand stakeholders

You need to understand the goals and priorities of stakeholders to be successful. Just because you’re happy with what you’ve accomplished doesn't mean your stakeholders will too.

Ensure your stakeholders are brought into your process early and often and help them understand how you work to provide them value. Gather feedback from stakeholders regularly to ensure your goals are aligned. A good time for this is during the sprint review. Just make sure those insights are transferred over to your next planning meeting.

Not choosing tools with a customer-centric approach

Successful product development delivers what the customer needs and wants. To build for your customers, it helps to use tools for planning and work management that makes it easy to keep them top-of-mind. Incorporating user story maps and customer personas into your planning helps you and your team prioritize the work that will deliver the most value first.

💡 Learn more: 10 tips for more effective user personas

Failing to incorporate retrospective insights into planning

Retrospectives are the best thing you can do to help your team work better together. During a retrospective, you're asking your team to be open and honest about how things went over the course of the sprint so that you can learn from each other.

Failing to learn from those insights means that the collective time spent in the retrospective has been wasted, and the feedback that your team has shared is devalued.

Incorporating the learnings you gain from a retrospective into your next planning session and into the next sprint, will support your team to improve every time, helping them gain work satisfaction and deliver better outcomes.

Virtual vs. in-person sprint planning

The advantages of remote work also bring challenges for collaborative planning. No matter the way your team chooses to meet, whether virtually, in person, or a combination of both, it’s important that you choose tools that meet the needs of your team.

Tips for virtual sprint planning:

• Be really prepared - communicate plans clearly ahead of time, so that everyone has clear expectations.
• Use a video conferencing tool that allows for breakout sessions
• Set up the interactive online resources you plan to use and include links in the meeting request.
• Online discussions don’t start as naturally as they would in person, so share discussion topics ahead of time, and consider preparing some ice-breakers.
• Ensure that you’ve accounted for time differences for teams that span time zones.
• Tech issues arise no matter how much advanced planning and testing you do. Always expect the unexpected.

Tips for in-person sprint planning:

• Book a meeting room with plenty of space for your team, and consider separate spaces for breakout sessions.
• Ensure that your meeting room will accommodate a shared view of your sprint plan - do you need a wall for sticky notes, or a screen to share a digital tool?
• If some of your team members work remotely, it’s difficult to involve them in the same way, so consider how this might work for your team. They won’t be able to read a whiteboard or sticky notes as easily, so a digital solution may be best.
• If you choose to plan your sprint ‘on the wall’, be sure to nominate someone to transcribe your plan into your work management tool at the end of the planning meeting.

No matter where your planning takes place, always remember to prepare your backlog ahead of time so that you can have focused and informed discussions during sprint planning.

Additional agile resources

We’re continually adding to our content library, which is filled with resources, how-to guides, product updates, and more.

📚 Add these to your list:

• Easy Agile Podcast Ep.20: The importance of the Team Retrospective
• Easy Agile Podcast Ep.18 Top qualities of an agile leader and team
• Easy Agile Podcast Ep.16 Enabling high performing agile teams with Adaptavist
• Being agile vs doing agile
• The Ultimate Guide to User Story Mapping
• The Ultimate Guide to Buyer Personas
• The Ultimate Guide to PI Planning [2022 SAFe Edition]

Using Easy Agile to improve sprint planning

Make your sprint planning smooth and effective with Easy Agile TeamRhythm. Transform your flat product backlog into a dynamic, flexible, and visual representation of the work to be done. Seamlessly integrated with Jira, with TeamRhythm you can:

• View your Jira stories, tasks, and bugs in context, aligned beneath their epics on the story map
• Drag and drop Jira issues from the backlog into a sprint
• Create new issues right on the story map
• Estimate issues on the story map, and gauge capacity with story point totals in each sprint swimlane
• Publish the sprint goal on each sprint swimlane, so it’s always top of mind
• Use filters to focus on the stories and issues that are most important now
• Group epics by a third level of hierarchy, to easily see how the work in focus contributes to the bigger picture

Easy Agile TeamRhythm also supports team retrospectives, with flexible and intuitive retrospectives boards created for every sprint. You can add retrospective items right from the sprint swimlane, so you don’t forget any important points. And you can turn retrospective action items into Jira issues that can be scheduled for future sprints, so you’re always getting better at what you do, and delivering for your customers.

Thanks for reading our ultimate agile sprint planning guide! If you have any questions about this guide, our other content, or our products, reach out to our team at any time. We love hearing from you.

We’ll continue to update this guide as we gain more agile planning insights, techniques, tools, and best practices.

Do you know the difference between agile vs. waterfall, and have you considered which is best for your business?

Don’t go chasing waterfalls — unless you’re seeking a project management methodology. 😁 The waterfall method is a common framework teams have utilized for years. But it isn’t the only way of doing things, and it may not be the best way, depending on the needs of your team.

In this post, we’ll cover the differences between agile and waterfall methodologies, including the pros and cons of each. We’ll also share a potential alternative called the hybrid method, which can provide the best of both worlds for certain teams.

Build a visual roadmap timeline of your Jira issues

Easy Agile Roadmaps

Try Now

Agile vs. waterfall

When it comes to agile vs. waterfall, these methodologies don’t share a lot in common. In many ways, agile is the answer to the limitations of the commonly used waterfall method. However, there are definitely still pros and cons to each framework.

Let’s dig into both of these methodologies in more detail.

The waterfall methodology

We’ll start off with the waterfall approach since it’s a little easier to explain. While the idea of a waterfall may sound majestic and bold, the waterfall method is fairly traditional and straightforward.

The waterfall model is used to describe traditional project management, where a project plan is laid out by a project manager before work begins. Project requirements and tasks are planned in advance and given to the team, who then work on one task and then the next until project delivery.

Tasks are completed in the order they were laid out in the original plan. The sequential order of tasks cascading from one to the next is what gives waterfall project management its name.

Waterfall is a widely used project management methodology, but it does have its limitations. The strict approach helps teams know what to expect through every step of a project, but it isn’t very adaptable, and it can lack input from the team as a whole.

This lack of flexibility has hindered modern teams. It makes it more difficult to switch gears if and when you need to. A predetermined plan doesn't leave much room for change, and it misses out on adapting to invaluable feedback from both stakeholders and customers.

Waterfall Pros

• Clear goals and objectives are provided at the outset.
• There’s a straightforward structure that’s repeated project after project.
• It’s easy for team members to understand what’s expected of them.
• There’s less general pressure on employees.
• It’s easier to learn the ropes, especially for new employees.
• Information is easily passed on to all team members.
• Success is measured by the completion of tasks, which provides faster gratification.
• Budgets can be more accurately predicted.
• The end result of a project is decided from the beginning, so the journey is clear for everyone involved.
• Most planning is led by one person.

Waterfall Cons

• The process is not as flexible as agile approaches.
• It’s difficult to foresee roadblocks and dependencies that could delay work.
• Work is not always evenly spread out across the team.
• Project overload is possible.
• Short-lived teams may ignore conflict for the sake of getting to the end of the project.
• It’s difficult to change directions or the scope of deliverables once a project begins.
• There’s less customer involvement throughout project or product development.
• Stakeholders may not see progress until the end of a project or until a final product is complete.
• There isn't an early testing phase to ensure a project or product is on the right track.

The agile methodology

Agile is an iterative approach that puts emphasis on testing and adapting. It uses early feedback and stakeholder involvement to determine the best possible path forward. There’s still a plan with agile, but it isn't rigid or strict, and it leaves plenty of room to adapt and grow along the way.

Easy Agile Roadmaps: The simplest and most flexible roadmapping tool for Jira

Try Now

The plan evolves as new information is acquired to ensure the end result meets customer and stakeholder needs. Adaptability plays a big role in agile practices, and that’s what has drawn so many teams to the methodology. The ability to adapt in the face of change is a sought-after strength today, given the pace at which change is occurring across technology, the economy, global markets, and more.

Agile Pros

• The entire team is involved in the planning.
• Feedback is central to the process.
• Customers and stakeholders are involved.
• The customer journey is top of mind when a decision is made.
• The team can adapt as new information is acquired.
• Changes can be made along the way to avoid roadblocks or stalled work.
• Each team member's capacity (workload) is continually assessed to prevent burnout.
• Long-standing teams continue to learn how to work together.
• Processes are continually improved upon throughout every phase of the project/product.
• All voices on a team, no matter the role, are heard when it comes time to gather retrospective feedback.

Agile Cons

• Agile techniques and terminology can be tough to grasp.
• It can take teams a while to learn proper agile methods.
• Agile teams may not get the support they require from management and business owners.
• Not all team members may buy into the agile framework, presenting a disconnect across the team.
• A lack of documentation can make the details unclear.
• Budgets can become unpredictable if it turns out the project/product needs to go in another direction.
• The scope of a project/product can continue to grow (scope creep).
• The many agile meetings take up a lot of time.
• It’s harder to find new employees who are experienced with agile methods.

Agile is a broad term that covers a number of different frameworks that utilize agile practices. Lean, DevOps, Kanban, and Scrum are all various forms of agile that fulfill different needs.

For example, the Scrum framework involves repeating sprints that are commonly used by agile software development teams. If you haven’t heard of Scrum before, this might be a lot to take in. 🤯

A Scrum takes two weeks, beginning with sprint planning, when the product owner makes prioritization decisions about which backlog items (tasks) should be accomplished in the upcoming sprint. From there, the team works on the specified tasks, guided by a Scrum Master who leads daily standup meetings to keep everyone informed of project/product progress. Lastly, a sprint review and sprint retrospective occur at the end of the sprint to ensure the team continually evolves and improves.

Easy Agile User Story Maps: Achieve smoother sprint planning & easier backlog refinement.

Try Now

Interested in learning about other popular agile methodologies? There are so many to choose from! We covered 8 popular development methodologies in a previous post.

The hybrid methodology

Does the choice need to be agile vs. waterfall? You might be thinking, can’t we put all of these benefits together? The hybrid agile approach can offer the best of both words for some teams.

A hybrid model blends the valuable techniques provided by both waterfall and agile frameworks. For example, you might begin with a set of agile sprints for prototyping and gathering feedback, followed by a single plan of action associated with non-agile techniques. It can be the best of both worlds, and it can serve as a stepping stone while a team attempts to make a complete agile transformation.

A hybrid approach often comes into play with agile project management and other non-traditional agile uses. Agile was originally designed for software development, but teams in all sorts of industries continually adopt aspects of agile. The agile methods observed by software developers don’t always work for other types of teams. Agile can be a difficult transition to make, especially when teams are used to things being done another way.

An approach that meets your needs

When choosing which approach is best for your team, business, or enterprise, take time to consider the needs of the team as well as your customers and stakeholders. Agile may be a tough transition to make, but if you believe the benefits will enhance your processes and help your business long-term, it might be time to make the switch. A hybrid approach can help you get there gradually without as many disruptions to your current processes.

Easy Agile is passionate about helping teams work better using  agile tools designed for Jira. If you want to learn more about agile and other methodologies, follow the Easy Agile blog. It’s filled with how-to guides, tips, and strategies — and if reading content isn’t for you, we have a podcast too! 📢

Businesses of the future need to make smart decisions with agility, and today’s customers expect a value-driven approach that considers their needs every step of the way. The agile methodology offers businesses of all sizes a new way of working that focuses on adaptability, collaboration, and continuous improvement. More and more businesses are looking to make an agile transformation, but no organizational change is ever easy.

Learn more about the benefits of transitioning to an agile methodology, the challenges involved in making the switch, and what makes a successful agile transformation.

An intro to the agile methodology

The agile process is very different from traditional project management, which commonly utilizes a rigid waterfall approach. Project goals and guidelines are laid out at the beginning of a project based on the information a project manager currently has. The team sticks to the plan until the project is complete, finishing one task after the next in sequential order, like a waterfall.

Agile, on the other hand, allows for flexibility and adaptability so that any plan can grow and evolve as you acquire new information. The agile methodology first gained traction in the software development industry because it provided a dynamic approach for solving complex and ever-changing problems.

Today, the principles of agile have spread across all sorts of industries and businesses of all sizes. As the world changes at a faster pace than ever before, businesses need solutions that can adapt. Making an agile transformation improves business agility with systems and processes that ensure continuous improvement.

Another key aspect of agile is it always seeks new information. As opposed to waiting until the final project or product is complete, stakeholders and customers can give feedback every step of the way. This allows teams to make decisions based on customer needs, and it ensures customer value is continually delivered.

Some of the many benefits of agile include:

• Eliminating wasteful procedures
• Breaking free from workplace silos
• Encouraging collaboration and participation
• Involving stakeholders and customers throughout the process
• Identifying and accounting for roadblocks before they occur
• Accurately managing each team member’s workload (capacity)
• Understanding the customer’s perspective
• Using better decision-making practices
• Adapting to new information
• Continually improving internal processes

➡️ Learn more in our Agile Beginner's Guide.

Agile transformation challenges

While the benefits of agile are abundantly clear, any large organizational change is difficult to achieve. Understand what challenges you will face throughout an agile transformation so that you can best prepare leadership, team members, and stakeholders.

It takes time and patience to learn agile principles

Establishing an agile organization doesn’t happen overnight. Understand that your transformation journey will take time, dedication, and patience. It’s a monumental change that you can’t rush or push onto team members without proper education, training, and support.

Plan the rollout in stages so that there’s as little disruption to business as possible. Take the time to teach agile principles to each section of the organization. Agile and all of its practices can be tough to wrap your head around for those who are unfamiliar with it. No matter how big or small your organization is, it’s crucial that everyone understands what changes are being made, the benefits, and what steps need to be taken to adopt an agile mindset.

Change can cause reluctance and push back

People are often reluctant to change, and in some cases, change can cause fear, stress, and anxiety.

Agile requires buy-in from everyone, but with such a deep and large-scale change, many people within your organization may be reluctant to make the switch. It’s natural for people to be wary of change even though change is all around us every day. Everyone experiences different levels of excitement, hesitation, and animosity when it comes to change, so ensure you give people space to adapt to your new way of doing things.

If you are getting push back, speak to people or have team leaders schedule one-on-one chats to address concerns. Understand that change is very difficult for people to work through, and dealing with change can sometimes be similar to the grief process. The stages of the change curve involve shock and denial, anger, bargaining and blame, and confusion, all before finally arriving at acceptance.

Give your organization time to adjust while underlining the benefits of agile, how it will improve the way they work, and how leadership and business owners will support the team. The success of your agile transformation relies on everyone embracing agile adoption, no matter their role.

Cross-organizational responsibility

With an agile process, everyone is responsible for ensuring things run smoothly and targets are met. There may be team leaders, but everyone is a key piece of the puzzle. This may not be what teams in your organization are used to, as often there’s a top-down, hierarchical approach to leadership in traditional management. Higher-ups may feel they're losing power while other team members will need to be more involved than they used to be.

Under agile, traditional organizational structures evolve into a much more collaborative process. It’s not just one person in charge who’s on the line if something is stalled or doesn’t work out. Everyone in the entire organization is an integral part of the agile process. Everyone needs to be accountable for learning agile principles, participating in the transition, and offering feedback. Active participation from all business roles needs to continue in order to fully access the benefits of agile.

Agile is difficult to scale across large enterprises

Implementing an agile framework across a small business or startup is much simpler to do. For starters, the fewer people you have to train, the less it will cost and the faster the agile transformation can happen. Smaller teams are better able to adapt and work with one another to adjust to changes. Startups are also naturally more agile and often consist of younger team members who are more ready and willing to adapt.

The larger the company or enterprise, the more difficult it is to implement any change, let alone a complete business overhaul and mindset adjustment. It will take a lot longer, and there’s way more that can go wrong, but that doesn’t mean these efforts aren’t worth it. It’s even more important in large enterprises not to lose sight of your customer needs, and there are plenty of opportunities to optimize your systems.

The good news is there are systems designed to help enterprises adopt agile practices. SAFe, the Scaled Agile Framework, was designed to help scale lean and agile practices across larger organizations.

➡️ Easy Agile is a proud Scaled Agile Platform Partner. Easy Agile Programs for Jira will streamline your process and empower your team to implement the Scaled Agile Framework (SAFe).

Need to educate stakeholders and get them on board

Stakeholders are an essential part of the agile process. In an agile transformation, your stakeholders and customers are used to the status quo. They may be completely unfamiliar with agile, and it’s up to you to get them up to speed and convince them of the benefits and the increased customer satisfaction agile will provide.

Ensure you schedule time into your transition to answer any questions stakeholders may have. In order for agile teams to be successful, you need to involve stakeholders and customers who will provide you with invaluable feedback. This feedback will improve your processes, ensure you produce a top-notch product (or project), and make sure value is continually delivered.

Work better with agile

Agile practices are no longer reserved for product development. They are widely adopted and utilized across businesses of all shapes and sizes because business owners and managers understand the power of agile.

Despite the challenges, an agile transformation is well worth the investment. It will take time and cost you money upfront to make the change, but as 2020-2021 proved, businesses survive best when their systems are flexible and adaptable. Applied correctly, agile helps your team internalize this mindset and practice it in daily work.

Easy Agile builds Jira plugins that prioritize the customer in every step of the development process, making the lives of Scrum Masters, product owners, agile coaches, leadership teams, and devops that much easier.

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.