Workflow

Software development teams are known for using a wide variety of agile methodologies, approaches, and tools to bring value to customers. Depending on the needs of the team and the product's stakeholders, it’s common for teams to deploy and utilize a combination of software development methodologies.

Most dev teams combine methodologies and frameworks to build their own unique approach to product development. You’ll find there are plenty of overlapping principles from one methodology to the next. The key is choosing a system and working as a team to fine-tune and improve that approach so you can continue to reduce waste, maximize efficiency, and master collaboration.

In this post, we’ll outline and compare the following eight software development processes:

1. Agile software development methodology

2. Waterfall methodology

3. Feature driven development (FDD)

4. Lean software development methodology

5. Scrum software development methodology

6. Extreme programming (XP)

7. Rapid application development (RAD)

8. DevOps deployment methodology

1. Agile software development methodology

Agile is the most common term used to describe development methods. It’s often used as an umbrella term to label any methodology that’s agile in nature, meaning an iterative process that reduces waste and maximizes efficiency.

Most software development methodologies are agile with a strong emphasis on iteration, collaboration, and efficiency, as opposed to traditional project management. It’s like comparing jazz to classical music. 🎷

Traditional, linear management methods, such as the waterfall method we’ll cover below, are like classical music, led by one conductor who has a set plan for how the music should be played. The agile process, on the other hand, is more like jazz, which comes together through collaboration, experimentation, and iteration between band members. It’s adaptive and evolves with new ideas, situations, and directions.

2. The waterfall methodology

The waterfall approach is a traditional methodology that’s not very common in software development anymore. For many years, the waterfall model was the leading methodology, but its rigid approach couldn’t meet the dynamic needs of software development.

It’s more common to see the waterfall method used for project management rather than product development. At the beginning of a project, project managers gather all of the necessary information and use it to make an informed plan of action up front. Usually, this plan is a linear, step-by-step process with one task feeding into the next, giving it the “waterfall” name.

The approach is plan-driven and rigid, leaving little room for adjustments. It’s more or less the opposite of agile, prioritizing sticking to the plan rather than adapting to new circumstances.

3. Feature driven development (FDD)

Feature driven development is also considered an older methodology. Although it uses some agile principles, it’s viewed as the predecessor of today’s agile and lean methodologies.

As the name says, this process focuses on frequently implementing client-valued features. It’s an iterative process with all eyes on delivering tangible results to end users. The process is adaptive, improving based on new data and results that are collected regularly to help software developers identify and react to errors.

This kind of focused agile methodology can work for some teams that want a highly structured approach and clear deliverables while still leaving some freedom for iteration.

4. Lean software development methodology

Lean software development comes from the principles of lean manufacturing. At its core, lean development strives to improve efficiency by eliminating waste. By reducing tasks and activities that don’t add real value, team members can work at optimal efficiency.

The five lean principles provide a workflow that teams use to identify waste and refine processes. Lean is also a guiding mindset that can help people work more efficiently, productively, and effectively.

The philosophies and principles of lean can be applied to agile and other software development methodologies. Lean development provides a clear application for scaling agile practices across large or growing organizations.

5. Scrum software development methodology

Scrum is a system regularly used by software development teams. Like many software development methodologies, Scrum is agile, focusing on a value-driven approach. The Scrum process is based on empiricism, which is the theory that knowledge comes from hands-on experience and observable facts.

One Scrum takes place over a preset amount of time called a sprint. Usually, the time frame is between two to four weeks and the Scrum is at the beginning of the sprint. The goal of each sprint is to yield an imperfect but progressing version of a product to bring to stakeholders so that feedback can be integrated right away into the next sprint.

The specific goals of each sprint are determined by a product owner who orders and prioritizes backlog items (the artifacts that need completion). The sprint process repeats over and over again with the development team adjusting and iterating based on successes, failures, and stakeholder feedback.

Learn more about Scrum — the complete program planning solution for Jira.

6. Extreme programming (XP)

Extreme programming, also called XP, is a methodology based on improving software quality and responsiveness. It’s an agile approach that evolves based on customer requirements; the ultimate goal is producing high-quality results. Quality isn’t just limited to the final product — it applies to every aspect of the work, ensuring a great work experience for developers, programmers, and managers.

Decision-making in extreme programming is based on five values: communication, simplicity, feedback, courage, and respect. The specifics of XP can’t apply to all situations, but the general framework can provide value no matter the context.

7. Rapid application development (RAD)

Rapid application development (RAD), sometimes called rapid application building (RAB), is an agile methodology that aims to produce quality results at a low-cost investment. The process prioritizes rapid prototyping and frequent iteration.

Rapid application development begins with defining the project requirements. From there, teams design and build imperfect prototypes to bring to stakeholders as soon as possible. Prototyping and building repeat over and over through iterations until a product is complete and meets customer requirements.

This is ideal for smaller projects with a well-defined objective. The process helps developers make quick adjustments based on frequent feedback from stakeholders. It’s all about creating quick prototypes that can get in front of users for constructive feedback as soon as possible. This feedback is pulled into the user design so that development decisions are based on the direct thoughts and concerns of those who will use the product.

8. DevOps deployment methodology

The DevOps deployment methodology is a combination of Dev (software development) and Ops (information technology operations). Together, they create a set of practices designed to improve communication and collaboration between the departments responsible for developing a product.

It's an ongoing loop of communication between product developers and Ops teams (IT operations.) Like so many agile processes, it relies on continuous feedback to help teams save time, increase customer satisfaction, improve launch speed, and reduce risks.

The steps of DevOps deployment repeat, aiming to increase customer satisfaction with new features, functionality, and improvements. However, this methodology has some drawbacks. Some customers don’t want continuous updates to their systems once they are satisfied with an end product.

Software development made easy

Most software development teams use a combination of methodologies and frameworks to fit their team size, team dynamics, and the type of work being completed. The key is to use an agile methodology and work together to continually improve your systems as you learn and grow.

Easy Agile is dedicated to helping teams work better together with agile. 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 deliver better for your customers.

Book a 1:1 demo to learn more about our suite of Jira tools, or contact our team if you have additional questions. We offer a free, 30-day trial, so you can try out our products before making a commitment.

A sprint backlog is like an agile team's treasure map — checking off each item is like visiting a different place on the map. By the end of a sprint or iteration, the team will have delivered previously agreed outcomes and ultimately achieved their sprint goal. This is like getting to the ✖️ on a treasure map.

Join us as we find the answers you need to successfully complete each sprint. You'll learn about a sprint backlog’s purpose, plus who creates, owns, updates, and uses it.

What's a sprint backlog?

A sprint backlog consists of the items that need to be completed in order to get to the sprint goal. It should go into artifact during the sprint planning meeting. A sprint backlog has three parts:

• The sprint. Each sprint backlog targets a specific iteration.
• The sprint goal. This is the higher level aim for each sprint. To achieve it, the development team completes certain items from the product backlog.
• A plan. The sprint backlog represents a plan to deliver a product increment by the end of the sprint. It's organized to allow for progress tracking with to-do, in-progress, and done items, plus effort estimations and remaining workload.

The sprint backlog should always be accessible and up-to-date so that the development team understands the work and can see what is coming up next. It should also have enough detail to allow tracking work progress.

Each sprint starts with a sprint backlog, and the artifact's lifespan equals the sprint's duration. You may expect to find work items — user stories, tasks, or bugs — in it.

The sprint backlog is the development team's go-to home to find all the ideas for what to work on. At every Daily Stand-Up,, the team looks at it to let others know what they did the day before. Additionally, they recall or adjust priorities based on what they need to do for the next day(s).

🧐 During the Daily Stand-Up, developers also use the sprint backlog to evaluate the sprint's progress.

The sprint backlog is not only a way of keeping the development team's eyes on the prize. 👀 It's also a way to discuss how well they achieved the sprint goal.

At any point in a sprint, to-do, in-progress, and done items are included in the sprint backlog for anyone to review and use to calculate the remaining workload. This helps verify if the development team is on track to achieve the sprint goal. ✌️

Jira provides a burndown chart to check the development team's work. This displays the remaining workload for the current sprint. In addition, the chart shows:

• Work in progress
• The distribution of work throughout the iteration

A Jira burndown chart also helps evaluate whether additional items fit into the sprint and effort estimations were accurate.

🛑 Keep in mind that you don't need a sprint backlog if you follow the Kanban framework. That’s because Kanban isn’t about working in timeboxes (the sprints).

Now, the sprint backlog isn't an off-the-shelf artifact that you can use in your project — every project is unique. So, someone must be responsible for populating the sprint backlog with work items.

Besides defining what a sprint backlog is, we should discuss what sets them apart from product backlogs.

Sprint backlogs vs. product backlogs

Though their names are similar, a sprint backlog and product backlog serve different purposes. A product backlog is:

• A collection of work items to either bring a new product to the market or improve an existing product
• A list of work items to tackle in the future
• A set of work items arranged by priority, with the most priority at the top
• The source of the sprint backlog items

On the other hand, a sprint backlog is:

• A subset of work items from the product backlog
• A group of items to work on during the next sprint

Here’s how the two backlogs meet: The product backlog provides work items for a sprint backlog. And, by the end of a sprint, the team might transfer incomplete work to the next sprint or the product backlog. If the work items have high priority, they should go into the next sprint. If not, they should go into the product backlog for a later sprint.

Essentially, a product backlog covers a greater amount of time than a sprint backlog. However, like the sprint backlog, the product backlog might evolve to reflect changes in the market or customer needs and, the development team needs both in order to deliver product changes.

Now, the sprint backlog isn't an off-the-shelf artifact that you can use in your project — every project is unique. So, someone must be responsible for populating the sprint backlog with work items.

Who owns and creates sprint backlogs?

Here are the team members involved in creating sprint backlogs:

• The Scrum Master. During the Sprint Planning ceremony, the Scrum Master uses the product backlog to create the sprint backlog — the output. However, the Scrum Master doesn't do it alone.
• The development team. When moving product backlog items to the sprint backlog, the Scrum Master considers the development team's input. ⚖️
• The Product Owner. The Scrum Master needs the Product Owner's agreement to include product backlog items in the sprint backlog. 👌 And if the development team has questions about the product backlog, the Product Owner is the one to ask.

The sprint backlog's creation is one part of the agile workflow that shows how essential teamwork is to agile. Nevertheless, the sprint backlog must always be owned by someone throughout the workflow. Otherwise, these artifacts can get lost and become outdated.

Scrum methodology says that the whole agile team owns the Sprint Backlog. And by "agile team," we mean the Scrum Master, the Product Owner, and the development team.

That’s because all agile team members contribute:

• The Product Owner knows what the development team should deliver by the end of the sprint. Plus, they order product backlog items by priority. In other words, the Product Owner constrains the product backlog items that should go into the next sprint backlog.
• The Scrum Master has enough experience to distribute the development team's work throughout the sprint. When considering sprint backlog item dependencies, that distribution makes the most sense.
• The development team knows how long similar Sprint Backlog items take to complete. ⏲️ This means they can determine the sprint goal's feasibility within a certain time frame.

Remember, the sprint backlog is a living document, so team members should update it as needed. Let’s look at how a sprint backlog can change.

Updating the sprint backlog

The sprint backlog should adapt to answer market trends and customer needs as they arise. Those changes might influence items in the product backlog and how they’re prioritized. As a result, the sprint backlog changes.

Let's have a look at what may cause a sprint backlog to change and who makes the updates:

1. Effort estimations were not accurate enough. If the development team realizes that some work items will take longer than expected, they should raise a 🚩. They should then negotiate the scope of the sprint backlog with the Product Owner without compromising the sprint goal.
2. A new, higher-priority user story, task, or bug comes up. If that happens, the development team should add it to the sprint backlog. That might impact the sprint's duration or push some items to the next sprint.
3. Progress in completing a user story or a task or solving a bug changes daily. As this happens, the development team should keep updating the remaining workload they estimated for the current sprint. And they should do it during the Daily Stand-Up or Daily Scrum meeting. Once the development team finishes all the work in the sprint backlog, they achieve the sprint goal. This means the development team implemented the product increment, which is ready for delivery. 📦
4. A sprint backlog item is no longer needed. This might be due to a shift in the market or customer needs. If that happens, the development team should remove the item from the artifact. 🗑️
5. The development team better understands sprint backlog requirements as the sprint continues. So, they might realize that to achieve the sprint goal, they need to include more items in the sprint backlog.

The sprint backlog: A guide for sprint success

A sprint backlog is a guide for completing a sprint goal. This means that its lifecycle is short and equals the iteration's duration. It's a visual representation of the sprint that supports Scrum team discussions on in-progress and to-do work.

This backlog may also be the most reassuring Scrum artifact for developers, as it assures them the work is organized and no additional work items will fall from the sky without their knowledge. If the workload must increase, the team will debate it and weigh the developers' experience-based opinion.

With a sprint backlog, the team perfects its ability to plan sprints, estimate effort, and allocate resources. They learn how long work takes and how much of it fits into a sprint. And by learning this, the team learns the resources they need to get to the finish line.

Easy Agile TeamRhythm is collaborative sprint planning tool that helps your team with the shared context that the story map format provides. TeamRhythm helps your team to:

• Visualize a meaningful picture of work on the user story map, sequenced into sprint swimlanes
• Create, estimate and prioritize user stories right on the story map
• See comitment at a glance with sprint statistics and sprint goals displayed on each swimlane

Try planning your sprints with Easy Agile TeamRhythm. We’re confident it will help your team collaborate even more seamlessly.

You can stick to manual Scrum workflow, or you can automate with free Jira software. We know which method we prefer.

Whichever you choose, implementing the Scrum framework creates a streamlined workflow. Each person has a specific role throughout the framework's steps.

The Scrum workflow provides team members with a simple process to help teams meet stakeholder needs.

While agile methodology aligns with Scrum, Kanban, and Lean, here, we’ll focus on what a Scrum workflow is and how this methodology can support organizational teamwork.

What is Scrum?

Teams use the Scrum framework to guide their workflow. Having a structure to follow means they can easily share, track and improve their deliverables.

Scrum divides work into smaller work parcels known as sprints, which typically last 2-4 weeks. Once the sprint is over, team members do a sprint retrospective meeting (also known as a sprint review) to chat about what worked well and what can be improved.

Scrum roles

Let’s look at the different roles that make up a Scrum team.

1. Product owner

The product owner has a core role in the Scrum workflow. They guide agile team discussions about product backlog items and features. In addition, product owners guide quality assurance to make sure deliverables are up to par.

2. Scrum Master

The Scrum Master will closely follow the principles in the agile manifesto to support sprint planning. Scrum masters guide development teams through agile methods to add value for stakeholders.

3. Software development team

Development teams are skillful and cross-functional. Teams that work in agile software development environments will typically include designers, developers, testers, and others to prevent the need for external assistance.

With the basics in place, we can take a closer look at the agile workflow stages.

Components of the Scrum workflow

The Jira workflow involves an iterative feedback cycle that focuses on creating value throughout the product development process. You can use the basic Scrum workflow steps or customize these.

The parts of an agile workflow are as follows.

1. Backlog development

A product roadmap guides team members in creating user stories and product requirements, which make up the sprint backlog. In the backlog, teams propose a list of features or user stories that the team must deliver. Product owners decide which features will make up the backlog.

2. Backlog release

Produce owner and team collaboration now decide which user stories will make it into each backlog release. Each backlog release is the completion of a smaller set of activities which eventually make up a sprint release. After completing this planning and setting timeframes for each action item, team members choose specific features for each sprint.

3. Sprint work

In a sprint, team members complete a set of backlog tasks within predetermined timeframes (usually 14-28 days). During this time, the agile team builds the product features from a specific sprint backlog.

Scrum or sprint meeting

Teams also hold Scrum or sprint meetings. During sprint meetings, the team sets a sprint goal (usually work on a specific feature). They agree on which product backlog items to complete in order to complete this product iteration. The team will prioritize, plan, and estimate the time needed to complete each task within the sprint.

Daily stand-ups

Agile teams use these daily standup meetings to track their agile workflow towards meeting sprint goals. Daily standup meetings are typically held — naturally — standing up, as they should last no more than 15 minutes. Standup meetings help teams discuss solutions to daily work issues.

4. The burndown chart

Team members can use Jira software to create their burndown charts. Burndown charts show original time estimates compared to real-time activities, which shows where expectations or team resources need to be adjusted.

5. Testing

During testing, the team demonstrates product functionalities for stakeholders. Feedback from product testing guides any needed changes.

6. Sprint retrospective and follow-up planning

The final phase of the Jira workflow is to hold a sprint retrospective. Sprint retrospectives are post-mortems on the previous workflow. At this stage, agile teams question what they did well, what didn't go as they hoped, and what changes they should make in the next sprint. Groups hold these sprint retrospectives to concentrate on better value deliverables through continuous improvement.

Jira software offers a visual display of the team's velocity, task progress, and project status. All these elements link back to the user story, and the group begins a new lifecycle to complete their project.

Create your Jira Scrum workflow in a few simple steps

You can either carry on using a manual Scrum process or transition to an automated Jira workflow for Scrum.

To create an automated, custom workflow, go to the Jira workflow designer. From there, you can manage the workflow scheme for your Jira project. You can also organize backlogs, complex workflows, workflow statuses, or view an issue status using custom fields.

In your workflow, you can:

• Use statuses like "In progress" or "Under review."
• View status items on lines for transitions.
• See issue resolutions.
• Check conditions that restrict assignee roles in bumping up issues to the following stage.
• Use validators to limit who can make transitions.
• Link further changes with transitions.
• Use triggers for automating transitions within specific parameters.
• Set workflow properties for transitions.
• Establish a link between the simple or complex workflow and issue types using workflow schemes.

As the agile team goes through the product lifecycle in a series of sprints, they need a tool to guide their journey.

With the free Easy Agile Scrum Workflow for Jira plugin, you can move Jira issues between the "To do," "In progress," and "Done" sections. You can also use the top right button to drag and drop specific issue types in the "Backlog" and "Selected for development" areas on the board.

More features from the Jira workflow plugin

In terms of automation, plenty of tools are available. You can use Easy Agile’s free Jira workflow plugin as valuable support for agile project management. This can help you create complex workflows and save all the details in the Jira cloud, ensuring nothing is ever lost. The free Jira workflow plugin also includes your burndown chart and sprint report.

Add the Confluence wiki tool to your Jira software for greater team collaboration. Also, use the Team Calendars add-on for better team collaboration.

Automate your Jira workflow now

Don’t wait for providence to come knocking on your door. Automate your Scrum workflow today with software that works.

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.

I was fortunate enough to travel to San Diego for the recent Global SAFe Summit. It was there that the folks from Scaled Agile Inc. unveiled SAFe 5.0 to the audience of 2,100 people from all around the world.

Like many in attendance, I was both excited and overwhelmed with all the changes including the refreshed Big Picture, renewed focus on customers and concepts of Business Agility just to name a few.

After the long flight back to Australia, and having had time to share my learnings with the team, we're super excited about what these changes mean for scaling organizational agility and we wanted to share a few of them here with you.

What's new in SAFe 5.0

1. Introduction of Business Agility

How is this different? Business agility now incorporates the whole business in the move towards value streams rather than individual departments.

2. Refreshed look and feel to the SAFe Big Picture

3. New SAFe Overview

4. SAFe 5.0 'revamps' 2 of the Core Competencies of the Lean Enterprise:

• Agile Product Delivery from DevOps and Release on Demand
• Enterprise Solution Delivery from Business Solutions and Lean Systems Engineering

Plus, Addition of 2 new Core Competencies:

• Organisational Agility
• Continuous Learning Culture

5. A 10th SAFe Principle was announced

NEW: Principle #10 - Organise Around Value

Why are we excited about SAFe 5.0?

It's not the updated Big Picture diagram, or the more approachable and "business friendly" overview that has us excited about SAFe 5.0. What we're more excited about than anything, is the renewed focus on customers - hooray!

While we enjoyed playing a customer version of 'Where's Wally?' in previous SAFe Big Pictures, this renewed focus on customers represents a shift in the level of maturity of organizations adopting SAFe.

They are no longer at a point where "doing" agile is their primary objective. This shift towards customer-centricity embodies what it truly means to be agile, where satisfying the customer is our primary objective.

We've also seen this shift more broadly, as customer/user satisfaction was cited as the #1 success metric for both agile initiatives and individual agile projects in this year's #StateOfAgile report.

How does SAFe 5.0 encourage customer centricity?

The revamped Core Competency of Agile Product Delivery (previously called DevOps and Release on Demand) is what really has us using emojis like ❤️ and has us feeling jazzed.

The DevOps and Release on Demand competency was all about "delivering value to customers" by forming value streams and optimizing continuous delivery pipelines to ship stuff into the hands of customers quickly.

The idea that value to customers = shipping working software more regularly is 💩.

A bad feature is still a bad feature no matter how much faster it lands in the laps of customers. Worse still, a bad feature that your customers don't use, didn't want, or doesn't make them better at their job...... I think you know where I'm going with this.

This revamped Agile Product Delivery competency instead places the focus waaaaaayyyy before anything is actually built - the first order of business should be having a customer-centric mindset by:

• focusing on the customer
• understanding their needs
• thinking and feeling like the customer #bethecustomer
• building a whole product solution
• knowing the customer lifetime value

How do we achieve customer-centricity?

Putting customers at the center of all decisions and incorporating Design Thinking practices into the mix well before we even think about building anything is key to achieving customer-centricity.

This all sounds great, but what does this look like in practice? The diagram below is probably our favourite asset in the entire SAFe catalogue and we think it showcases practical examples of Design Thinking in practice:

Our personal favourites

Personas 💁🏽‍♀️

It might seem trivial at first, to come together as a team, creating what seem like fake dating profiles for your customers.

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

Teams that have a shared understanding and alignment around the types of people using the solution they are delivering are more likely to succeed.

We want to make sure we're building the right solutions, for the right people, to help solve the right problems at the right time, otherwise we risk the following scenario:

Knowing the customer deeply is no longer the sole responsibility of a (traditional) Sales and Marketing team. Agile practices have called for the development of cross-functional team members to step up and help connect with customers.

Related blog post: how to create personas with your team.

It's no secret as the makers of Easy Agile TeamRhythm that we love user story maps (shameless 🔌).

So what about this agile practice do we love so much that we decided to form a business off the back of it?

The purpose of engaging in this activity is to create a shared understanding of who our customers are, how they interact with our products and how we should focus our development efforts on stories in order to provide our customers with the most value.

In other words, it gives us a way to say, ok I'm working on building this user story, I know who the user I'm building this story for is, and I can understand which part of the customer's journey this will be directly impacting.

We believe this shared understanding is incredibly powerful for both building with empathy and putting our customers at the heart of of all our development decisions. We believe this practice exemplifies what it means to be customer centric, and that's why we ❤️ it.

Verdict

Easy Agile welcomes the big changes introduced in SAFe 5.0, especially calling out customer-centricity, design thinking, and business agility. We can't wait to see how our customers start introducing this to their teams.

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

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

Tuesday March 8 AEDT

REGISTER NOW

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

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

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

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

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

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

Try Easy Agile Programs for Jira

Free Trial

Major benefits of implementing SAFe

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

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

Register

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

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

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

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

Beginning to use SAFe: The big picture

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

1. Leading SAFe

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

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

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

Leading SAFe course

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

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

2. Implementing SAFe

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

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

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

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

Implementing SAFe course

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

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

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

More SAFe roles and processes

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

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

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

Register for Easy Agile Programs Product Demo

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

Try Now - Free Trial

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

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

SAFe training for better enterprise agility

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

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

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

Streamline visibility and provide transparency of your Program

Easy Agile Programs Product Demo

Register Now

Many organizations struggle to manage large-scale projects. SAFe can help.

SAFe gives you the framework and training that you need to make a sustainable change on a large scale. If you want to change on a small team level, department level, or across the enterprise, SAFe shows you how.

There are many benefits to implementing SAFe. But what exactly is it, and how can you use SAFe to help create a lean enterprise?

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

Try Easy Agile Programs

JOIN A DEMO

SAFe background

SAFe is the acronym for “Scaled Agile Framework.” As agile focuses on small-scale continuous improvement, SAFe uses its philosophy at an enterprise level.

SAFe increases business agility, resulting in flexible and responsive teams for large organizations. SAFe uses its own set of values along with Lean-Agile principles.

This agile framework started when software systems expert Dean Leffingwell became frustrated with traditional work processes in the software industry. He developed the SAFe method to help change work processes that reaped results.

You can use this framework to instill a Lean-Agile mindset on a large scale. It focuses on constant improvements. As a result, enterprises improve work performance and productivity.

You can access training through Scaled Agile Inc. to scale work and improve performance in your enterprise.

Implementing SAFe at the team, program level, or enterprise is completely doable.

Try Easy Agile Programs for Jira

SAFe values

The Scaled Agile Framework uses four core values:

1. Alignment of business decisions with the business vision, strategy, implementation and goals on a small to large scale.
2. Built-in quality to produce desirable outcomes that create success.
3. Transparency: Good decisions can only be made when comprehensive information is available.
4. Program execution that links back to strategy and vision

By applying these values, teams and organizations increase engagement by making it clear what they expect of agile team behaviors and actions.

When everyone works together and understands their responsibilities, the chance of success increases dramatically. SAFe encourages openness and engagement in meeting individual and team responsibilities. So, if an individual or team hits a roadblock, they communicate to find joint solutions to problems.

At scale, organizations use Lean-Agile methodology to:

• Drive the on-time delivery of software development products
• Support quality product deliverables
• Increase stakeholder engagement and satisfaction
• Streamline performance based on regular, predictable schedules

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

JOIN A DEMO

What is agile?

SAFe applies the agile methodology to larger teams. So, let's cover what agile means.

Agile methodology focuses on flexibility, collaboration, and value delivery. It means constantly adapting, or iterating, a product based on changing user and stakeholder needs. Agile teams rapidly respond to change and quickly adapt, whether they use Scrum or Kanban.

Every iteration has a set timebox. Team members use these increments to support streamlined workflows. They create, test, and deliver outcomes that work better than traditional work processes.

What is Lean?

Lean methodology also plays a role in SAFe.

The Lean method has its roots in the auto industry. Ford motors, Toyota expanded on Ford's methodology to further minimize waste and deliver value. Now, Lean has a more comprehensive set of principles with practical applications.

Lean highlights the importance of reviewing value streams to improve efficiency and create more customer value.

When you use Lean principles, teams create more value, higher performance, and increased productivity. In other words, Lean supports business agility.

SAFe incorporates this Lean method of work. So, you can also apply SAFe to lean portfolio management (LPM) and many other areas of the organization.

SAFe Agile principles

The SAFe Agile framework also focuses on 10 SAFe principles. These principles help link performance, quality, and profits.

1. “Take an economic view.”
2. “Apply systems thinking.”
3. “Assume variability; preserve options.” This means no one solution is correct, so teams should keep an open mind when discussing work approaches.
4. “Build rapidly in increments to hasten learning cycles.”
5. “Create milestones on objective analysis of working systems.”
6. “Envision and restrict WIP, limit work batch sizes, and control queue lengths.” Any stoppages and problems lengthen the time to market, increase the use of scarce resources and reduce potential profits. In short, “time is money.”
7. “Apply cadence, synchronize with cross-domain planning.”
8. Encourage the innate motivation of knowledge within Scrum teams
9. Spread the decision-making process
10. Organize goals and work around the value that it creates

What is SAFe’s big picture?

If you’re having a tough time trying to visualize SAFe, let’s look at the big picture. Whereas the typical agile team is smale, SAFe offers a way to scale agile methodologies to larger organizations. It focuses on cross-team collaboration and motivates everyone to adopt a Lean mindset.

This means streamlined work processes and a clearer understanding of which processes create value. It also encourages larger teams to constantly adapt  and improve.

The framework shows how strategic planning can transform into practical work execution. Agile teams use the Agile Release Train (ART) to collaborate at each level of work to make this happen. SAFe also offers training to become a Release Train Engineer to support change.

At each level, the framework also indicates the SAFe principles that teams must use. By using these principles, they achieve value creation via coordination and a flexible workflow.

Create and visualise dependences within a single team or between teams

Focused Team Planning

Join a Easy Agile Programs Product Demo

The benefits of implementing SAFe

Leaders and employees can see the SAFe roadmap and workflow. They can also see the large-scale impact on business agility.

Some of the benefits of implementing SAFe include:

• Improving systems thinking across the organization
• Improving value streams and quality outcomes
• Increasing productivity
• Developing team environments through lean thinking
• Decreasing time-to-market
• Creating specific methods to achieve goals
• Generating transparency that clarifies roles, responsibilities, and action
• Removing silos and aligning smaller teams with the greater whole of the organization
• Increasing business agility to meet overall organizational goals

SAFe Agile certification

You can take advantage of certified SAFe Agile training courses to upskill your agile teams. Scaled Agile Inc. offers various training courses to manage Agile transformation.

SAFe training courses can help you implement SAFe methodology, lead SAFe teams as a SAFe Scrum Master, and manage Lean portfolios in SAFe.

SAFe + Jira = Success

Combine SAFe and Jira, and you have a comprehensive framework for success. After starting with SAFe, enterprises report significant, quantifiable improvements in implementing strategies.

Check out Easy Agile Programs for Jira. This app helps align teams at scale with its Program Roadmap. Viewing dependencies and other milestones at the ART level. Try it for free.

Try Easy Agile Programs for Jira

Get ready for remote user story mapping.

Whether you've done user story mapping before (in person) or you're new to user story mapping, there's a very good chance that you'll need to do remote user story mapping for the first time in 2020.

Even before the pandemic, 4.7 million people in the US worked remote, and an estimated 31% of US workers employed in March 2020 were working from home by April 2020.

And after lockdown ends, it’s likely we’ll see permanent changes to the way we work. Surveys show that 80% of employees are keen to work from home at least some of the time. Plus, more organizations are realizing that offering flexible, remote work options can lead to better work-life balance for employees, lower overheads, lower environmental impacts, and improved productivity.

...which is all to say that remote user story mapping is about to be the norm.

So, what do you need to know before you run your first online user story mapping event? Let's go through 8 things you should consider for successful remote user story mapping.

1. Get the basics right

First thing's first: you need your basics sorted. Make sure your team understands what user story mapping is, why user story mapping is important, and how to do it.

This will help get them onboard - which is critical, because you'll need them to commit two full days to the process.

If anyone on your team is new to user story mapping, send them to our user story mapping ultimate guide. It's got everything they need to know 👌

2. Set your agenda

User story mapping should be a scheduled event. You should know what's happening and when to make sure that your team stays on schedule and completes all the steps required to produce a finished story map. Here's a fairly standard agenda:

Knowing your agenda is especially important for remote story mapping, because it's a lot easier to veer off track when people aren't physically in the room.

Sally might head to the kitchen for a long lunch and miss the most important bit. Or Bob might need to coordinate his schedule so that his partner can mind the kids for a solid hour or so while he's involved in estimating the work.

Setting the agenda ahead of time will also help your team start thinking about the session and user stories before the event. That way, they’ll feel more prepared and ready to participate in discussions.

By the way, if you’re not familiar with all the items in the above agenda, we talk more about the specific steps and how to do user story mapping in our ultimate guide to user story mapping.

3. Plan your session

When are you going to hold your live online user story mapping session? Most teams need a full two days to work through all the steps, so you'll need to find two days (ideally in a row) when everyone is available.

If your team is located across multiple time zones, you'll also need to consider what times give you the best crossover so that team members aren't working at 2 am (unless they want to).

4. Decide on who

Remote user story mapping could present you with a bit of a conundrum. Unlike in-person events where you're limited on space, you could technically have unlimited people chime into your virtual session. But you definitely don't want that - too many people will make you inefficient (and they could use their time to add value to your business in other ways).

It’s a good idea to cap your numbers at around 12 people. Include team members and stakeholders across multiple departments, along with your product manager, UX designer, and developers.

Also decide who is going to lead the session and who will be responsible for creating the story map.

The good news is that online user story mapping makes it easy to record sessions - you'll have a digital record of your conference calls and your story mapping board. So anyone who's curious can easily catch up on the highlights once your event is over.

5. Make some rules

Working and collaborating remotely can feel a bit like the wild, wild west - especially the first few weeks or months. Everyone's still figuring out how to make this thing work - and how to get things done effectively in a new environment.

We've all been to conference calls where somebody didn't know proper etiquette or their audio/video ended up distracting other attendees.

So, with that in mind, here are some rules you might like to share ahead of your remote user story mapping session to make it a little less chaotic and a lot more productive:

• Don’t be late
• Put your camera on
• Save your food for a designated break
• Don’t take your device for a walk
• Close your door, if you can
• Stay focused on the task (no checking emails!)
• One person talks at a time
• Wait until everyone has had a chance to provide input before moving on
• If you’re not talking or participating in the conversion, mute yourself (to avoid interference or background noise that could stop people from focusing)

Of course, be realistic. Your team members are likely working from home in less-than-ideal circumstances, whether they're quarantined with family members, stuck at home with a sick child, or dealing with a bad-mannered house dog.

There will be noise and disruptions - and despite their best efforts, someone will be late. As long as people do their best to hit the mute button at the right time and consider others, your session should run smoothly.

6. Get your tech ready

Previously, you might have been able to show up to a user story mapping session with just your brainy self and a pen 🧠🖊️ You'll still need your brain for remote user story mapping, but you can ditch the pen.

Instead, you'll need to make sure you and your team have access to the technology they need to participate and collaborate online. Things like:

• Zoom, Google Hangouts, or Skype access - Everyone should have their account ready to go, along with some experience using the platform
• Slack or Microsoft Teams - Set up real-time chat for when you’re not in a video conferencing session
• Headphones & Microphone - These should be working well and tested ahead of time
• Webcam - While not strictly necessary, a webcam will help you replicate the feeling of being in the room together
• Internet - Ask your team to test their connection and make sure it's reliable - and ideally, have at least one backup option (like a local cafe, friend's house, or mobile hotspotting)

The right technology will allow you to adapt the user story mapping process to work for your remote team.

7. Get user story mapping software

A physical user story mapping session usually involves a long sheet of paper or cardboard, with hundreds of tiny post-it notes for each story and backbone item, and string to show cut lines.

The good news is, if you're doing remote user story mapping, you won't need to clear out your nearest stationery supply store 🎉 But you will need to equip yourself with some digital tools to replicate the physical story mapping board online.

There are a few user story mapping tools on the market, but we're partial to Easy Agile User Story Maps. It plugs straight into your existing Jira workspace, allowing you to:

• Visually map your customer journey
• Assign stories to epics
• Prioritize and sequence stories
• Arrange stories into sprint and version swimlanes
• Add story point estimates

It’s just like physical user story mapping, but done digitally inside of Jira. That makes it perfect for running a remote user story mapping session.

Okay, so we may be a little biased, but these people aren't:

Want to give it a spin for your upcoming remote user story mapping session? Sign up for our free 30-day trial to see the benefits for you and your team. We’re confident you’ll love what you find!

Try it now

8. Integrate your workflow

Last but not least, make sure that your remote user story mapping session integrates with your workflow

Good news! If you use a digital user story mapping tool (like Easy Agile's), you'll find it much easier to integrate your story map into your workflow. Once your user story mapping session is finished, your user stories are already set up in Jira, and organized into sprints or versions so that your team knows exactly what they need to work on next.

(Although they might want to take a day or two to ease back into it...😴)

Set yourself up for success!

With the right preparation and tools, you'll set yourself up for a relatively smooth remote user story mapping session. And after that? You'll be set to do your future story mapping events in a more streamlined, digital way, whether you're required to work remotely, collaborate with a distributed team, or work from the office.

And based on the way work is changing in 2020 (and beyond), that's a very good skill to have.

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

What is an agile retrospective?

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

The focus of the sprint retrospective meeting

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

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

Here are the four question areas for discussion:

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

1. What went as planned?

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

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

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

2. How could the team have improved?

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

Here are some ways to make this question more concrete:

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

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

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

In this round, the team should discuss:

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

4. What still confuses the team?

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

Here, it’s important to talk about:

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

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

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

Retrospective template options

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

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

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

1. Start, stop, continue

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

2. Four Ls

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

3. Starfish

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

4. Sailboat

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

5. Mad, sad, glad

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

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

Decide on your retro template today

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

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

Team retrospectives right inside Jira

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

TRY EASY AGILE TEAMRHYTHM FREE FOR 30 DAYS

The perfect product launch is an elusive beast. As the launch date nears, the pressure mounts while the product manager deals with last-minute changes, bugs infesting the Jira board, and some network or server issue that threatens to ruin everything. You might have the perfect product management framework, yet the journey to the finish line is usually anything but elegant.

Whether you're launching a new product or releasing a new feature, product managers thrive on the excitement, exhilaration — and exhaustion! -— that come with the job, particularly surrounding significant releases. Even with careful planning, an exquisite product roadmap, and a neatly refined backlog, the final moments before launch always seem to end in a fight to the finish.

Before you place all the blame on your product management framework, or worse, your product team (Nah, you would never do that!), take a step back and breathe. We’ll walk through some ideas on how you can relieve some of the chaos on launch day. (Let's be honest, no drama on launch day would be just a little disappointing.)

Pre-launch planning

If you're using an agile product development methodology like Scrum or Kanban, you're already ahead of the game in terms of planning. Experienced PMs will have a roadmap with t-shirt sized epics and stories carefully laid out using established prioritization methods.

Based on your product strategy, you may choose to release new product features to production after each iteration. But sometimes, the product marketing plan requires a bigger splash. In this case, you can take advantage of press releases, major advertising events, or other high-visibility marketing opportunities.

Planning how you intend to release the product is as important as deciding what will be part of the release. Product development teams need to coordinate with product marketing to consider the following:

• Will you do a soft launch to a limited audience?
• Do you need to pre-release specific components to test pricing, marketing copy, or usability?
• Will you leave pre-releases in the wild until launch, or will you test for a specific time period and then pull them back?
• Do you have a hard date on which you must release (ex., Super Bowl Sunday), or is there some flexibility in the timing?

Answers to these questions drive the release strategy, which is then factored into your release plan and execution.

When it comes to determining what features to include in your product launch, you can choose from a variety of product management frameworks or use a hybrid approach and mix and match the methodologies to fit your situation.

The Kano model, AARRR (acquisition, activation, retention, referral, and revenue) theory, and OKRs (objectives and key results) all provide product management frameworks. These help product owners plan feature releases that align with the product vision and realize profitability objectives.

Remember: It's always a good idea to have a Plan B or even a Plan C to allow for unexpected events or issues that tend to rear their heads just before a launch. Atlassian has a great product launch template to get you started if you're working on your first release.

Launch day planning

A launch day checklist is your best friend on launch day. You might even want or need more than one list. A product launch has too many moving parts across too many teams for you to rely on memory alone. Your marketing, IT, and product teams will all play a role in the launch, performing necessary activities for their roles.

Particularly if this might be the first product launch in your startup, checklists help product teams think through details with clear heads well before launch day. The best plan is to ask each team to create their checklist and then meet as a group to align and coordinate each task's timing. Some launch day tasks are independent, ready to be tackled at any time. In contrast, others will be more time-sensitive or dependent on something else happening.

For teams with a few launches under your belt, these checklists hold the lessons learned from prior releases and, when updated after each launch, turn your team into a smooth-as-silk, product-launching machine.

Post-launch planning

As you know, a product launch is not the end game. Once the dust settles and everyone has gotten some sleep, you need to measure how the product performs. Planning how to measure the product’s initial key metrics allows product managers to communicate results to stakeholders early and as often as necessary.

Measuring key product metrics after a launch validates your decision-making of the product features, confirms you built the right product for the market, and helps you ask and answer the right questions when planning more feature builds and marketing strategies.

Important key product indicators following the launch can include total sales, top attribution channels, activation stats, and affinity sales. If you're launching a new feature within an existing product, you'll also want to keep an eye on retention numbers. A spike in churn rates could indicate a problem with the user experience or the underlying technology solution.

Beyond measuring the results of your release, you'll also need to prepare what's next. After your development team gets some shut-eye, they'll come back to work looking for their next assignment. You'll need to have your backlog ready for the next sprint planning ceremony, and then, it's back to business as usual. There may also be some immediate customer feedback that needs to be actioned.

Once you get your team off and running toward the next release, it’s time to take a look at your roadmap. You’ll likely discover new information when customers start using your new product or feature. It’s a good idea to leave some room in the roadmap to take on work discovered during the first few weeks of your launch.

Then there’s one last thing — CELEBRATE!! You and your team worked hard and accomplished something really cool! It’s easy to get caught up in the daily grind toward the next release. Take some time to pat yourselves on the back for a job well done.

Use your product management framework to tackle launch day like a rock star

With some planning and flexibility, you can set up your product team to make launch day look like a walk in the park. And the sooner you get good at this, the better. You'll always be launching something throughout the product lifecycle, from the initial MVP to new features to the end-of-life process.

Thorough roadmapping gets you off to a solid start, and as you get closer to launch day, you'll build out more of the critical details to ensure you don't miss anything. Cross-team coordination is essential, and checklists help open communication channels and get the entire team on the same page.

Early reporting on results builds confidence with stakeholders and is also a great way to show your team the results of their efforts.

Enjoy the adrenaline rush of launch day, but try to eliminate a little of the chaos and stress. As soon as you've launched, it's time to move on to the next thing. That's the nature of product development, and that's why we love it.

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

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

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

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

1. Set clear goals and define what success looks like

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

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

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

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

2. Get to know your audience

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

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

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

3. Gather feedback and test, test, test

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

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

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

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

4. Use comprehensive tools to track product launch planning

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

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

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

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

5. Focus on an initial great product, not features

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

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

6. Expect the unexpected

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

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

7. Hold a retrospective after the launch

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

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

Let’s recap those strategies one more time:

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

2. Get to know your audience.

3. Gather feedback and test, test, test.

4. Use comprehensive tools to track product launch planning.

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

6. Expect the unexpected.

7. Hold a retrospective after the launch.

Learn more on the Easy Agile blog

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

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

We often get questions about why product roadmaps are considered an agile tool. To some, it seems quite “un-agile” to set concrete dates for a long list of tasks you will likely never get done.

That assumption couldn’t be more wrong. It presumes that a product roadmap is an old, overdone practice more akin to Waterfall predecessors like the *cough*Gantt Chart *cough*. This is not the case. Gantt Charts are for task dependency, and they assume that work will be completed in a linear fashion.

On the other hand, a true product roadmap is completely subject to change. It’s a living document meant to serve as a guide. The roadmap shows what a team needs to accomplish to create specific features or otherwise complete tasks that will provide the most value to customers in a certain timeframe.

This flexibility allows product development teams to make the most informed choices. To help teams do this, we built the simplest and most flexible roadmapping tool for Jira (more on this later). Here, you’ll learn about the benefits of using product roadmaps, the guiding principles of the roadmapping process, and how to use roadmapping tools effectively.

What is an agile product roadmap?

Agile is a broad term for a non-linear way of working that prioritizes flexibility and collaboration. This working style helps teams iterate as they go rather than stick to a rigid plan that doesn’t adapt to new information.

Think of agile as the complete opposite of an assembly line process for making a product. An assembly line has a strict plan where one step happens after the next. Each piece falls into place one after another without extra input or iteration.

🖍 Great for an assembly line of Crayola products, not so great for software development. 📱

Rather than use the assembly line approach, agile teams work collaboratively and iteratively on new products in order to detect roadblocks early, before they can cause a delay. And, Product teams use agile tools to provide clients and stakeholders value on a consistent basis.

Basically, agile product roadmaps are key to producing a great product.

They provide a smooth and collaborative planning process for development teams while maintaining the strategic objectives and product vision stakeholders expect. On top of all that, the flexibility provided by agile product roadmapping delights customers by consistently meeting their evolving needs, whims, and desires.

The benefits of roadmapping for product management

There are many benefits of roadmapping for everyone involved. Roadmapping assists product managers, helps the development team collaborate, gives stakeholders a clear view of the process, and ensures customers are continually pleased with product features and functionality.

Effective roadmap tools can provide the following benefits:

• Enable teams to align their vision around product features
• Provide a clear visual of the most critical prioritizations
• Ensure short-term product goals are met as soon as possible while monitoring and adjusting long-term goals
• Align all team members on what’s most important at any given time
• Keep track of specific product launch and release dates
• Maintain the product vision and business goals
• Ensure all stakeholders can view and give feedback on the current product plan
• Ship a product and solve issues relatively quickly
• Bring constant value to stakeholders and customers

For most teams, it’s truly the beating heart of product development.

4 guiding principles to get the most out of your product roadmaps

We’re obsessed with roadmapping and the many agile strategies that help teams work more effectively. So, we pulled together a list of the most important guiding principles that will ensure your agile team gets the most out of your product roadmap.

1. Focus on themes of work, not features

In the simplest form, themes represent high-level groups of work (like epics). In an agile product roadmap, themes should be customer-focused, unlike traditional waterfall roadmaps where themes tend to focus on business objectives.

Examples of themes include:

• Customer onboarding experience
• Reducing tech debt
• Customer satisfaction and engagement

By grouping work into themes, teams are able to tell a story about where they are headed as well as the goals, objectives, and outcomes that will get them there. User stories provide high-level visualization so that teams can answer critical questions:

• What are we doing?
• Why are we doing it?
• How does it link back to our Objectives and Key Results (OKRs)?

2. Think of the roadmap as a living document

Product managers need to educate their stakeholders on the true purpose of the product roadmap to manage expectations and ensure everyone is on the same page.

A product roadmap is not a promise. It’s a living document that’s meant to serve as a flexible guide.

You need to teach all stakeholders that the roadmap represents chunks of work, such as new features, functionality, and metrics customers value most at a specific period of time. It’s inevitable and expected that customer needs and preferences will change. The roadmap should be adjusted and amended to reflect these changes as time goes by.

The agile product development process should change to maximize the value customers experience. This is what it’s all about!

3. Actively collaborate with stakeholders

Involve everyone in the process, including internal stakeholders, external stakeholders, and the full development team when planning, reviewing, or adjusting the roadmap.

The product manager doesn’t need to be the only one representing the customer’s voice. By gaining the perspective of developers, the sales team, customer support, and engineers, you get a holistic view of the customer experience. This will give you a clear view of what your customers value to determine what should be done when.

4. Ensure the roadmap is accessible to all stakeholders

The product roadmap should be the team’s single source of truth, representing the plan of execution against the company's Objectives and Key Results (OKRs).

Understanding what’s going on and why each person is doing what they’re doing is crucial to establishing transparency and confidence in your team.

The roadmap represents the team’s overall vision for a period of time. Ensuring the roadmap is accessible to all stakeholders achieves organizational alignment.

Product strategy with Easy Agile roadmaps for Jira

We teased above that we’d tell you more about Easy Agile Roadmaps. We designed the simplest and most flexible roadmapping tool for Jira. Our roadmap software helps teams align around a product vision to sequence the most critical features for customer delivery.

Easy Agile Roadmaps are designed for everyone involved in the product development process from the product manager to the dev team to key stakeholders and customers. It works seamlessly with both Scrum and Kanban Jira Software boards. And, of course, it’s completely agile. Like, Simone Biles flexible.

Say goodbye to clunky Excel sheets, one-off Powerpoint presentations, and static Gantt Charts. Easy Agile Roadmaps can create a visual roadmap timeline that’s flexible, iterative, and easy to use. Split scheduled work, add date markers, use Quick Filters, track your progress, and export the roadmap as needed. The tool uses a simple drag-and-drop functionality for a clean user experience, no matter the needs of your team.

We’re so sure you’ll love it, you can try it free for 30 days. If you have any questions, our team is ready and waiting to hear from you, or watch an on-demand demo of our roadmapping app in action.

Let's face it! Project management for agile teams can include a lot of tough calls, from managing product owner expectations or undefined quality standards.

Sure, you have good days and bad days. But why not set your sights higher and aim for the ideal day?

To help you do just that, planning poker, also called Scrum poker, uses playing cards to simplify agile estimating and planning. The result? Your agile estimating and planning process runs more smoothly, and your development team increases its productivity.

In this article, you’ll explore the driving force behind planning poker,  how it helps estimation, planning poker’s history, and how to play this game.

The driving force behind planning poker

The purpose of planning poker is engaging the whole team in collaboration. Scrum poker makes it easier to make valuable time and effort estimates so your team can create satisfying deliverables.

Instead of team members verbally expressing their estimates, they use a deck of playing cards to speak for them. Drawing cards and simultaneously placing these playing cards face down eliminates bias. Everyone follows this route in the estimation process, which supports individual estimates and negates peer influence.

Other project estimation techniques use time to determine how long a task will take. Agile estimation uses story points. These story points refer to the level of effort to undertake a task.

In planning poker, the whole team assigns story points to each task. Each story point is a visual representation of the amount of work to be done and the effort that must go into completing each task. This method wins out over time since it is visual and focuses on effort involved instead of time constraints

Work estimation in agile development

The estimation process is vital to team members because it determines how much work will go into each sprint. Dividing the product backlog into bite-sized tasks helps evaluate the workload.

As a Scrum master, you have a difficult role to play. At the end of the ideal day, you want the product owner's user story to be exemplary. Simultaneously, as the Scrum master, you have a Scrum team to manage.

Agile development is a critical process that you need to control. Get the user story and story points right, and you're halfway there. Master the estimation process and sprint planning, and you control the product backlog and retrospective.

Software development teams can either use physical playing cards or software for planning poker. Using software that includes a Jira plugin is vital when you have distributed teams. When you have a Jira plugin, everyone can participate in and streamline the estimation process.

History of planning poker

Software development teams used to use another team-based estimation technique, Wideband Delphi. Although similar to planning poker, it took too much time to reach consensus with this technique.

James Grenning found that Delphi didn't work as a structured estimating approach and came up with the idea of playing poker in 2002. Grenning found that a physical deck of cards was an engaging approach for agile teams to make work estimates. He also found that Scrum poker worked better than Wideband Delphi.

Planning poker is more inclusive. The deck of cards ensures Scrum team participation in work estimates, and everyone must continue to participate until consensus is reached.

In 2002, Mike Cohn developed mountain goat software and stepped in with a deck of digital cards to use in planning poker. Scrum teams can use these digital playing cards from remote locations to improve agile estimating and planning and have some fun along the way.

Let's explore the ins and outs of the poker session and how to play the game.

What Scrum teams need for a poker session

Agile teams need a few essential items for their planning sessions. These items include:

• A deck of cards
• Estimators (the agile team)
• A moderator
• A features list
• An egg timer

Choose your playing cards

In Scrum poker, team members (estimators) each have a deck of cards. They use these playing cards to indicate their high or low estimate on how long each item on the list of features will take to complete. These list features can be the user story, story points, or ideal days to complete sprint planning.

The playing cards the development team use will follow a Fibonacci sequence. This Fibonacci sequence follows the 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144 pattern, where each consecutive number is the sum of the two preceding numbers.

Alternatively, team members can use a different deck of cards where the value of each number has a fixed ratio, such as 1, 2, 4, 8, 10, 12 and so on.

Different card decks provide adapted sequences, such as 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, and 100. Other commercial decks have cards to indicate that the agile team needs a coffee break or an infinity symbol which means that it is impossible to complete a task.

Similarly, team members can adopt a standard deck of cards for Scrum poker. Here, the team members use the Ace, the 2, 3, 5, 8, and the King.

How to play Scrum poker

Every Scrum team will have different goals, but the general sequence for playing planning poker is as follows:

• All team members have their own deck of cards except for the moderator.
• Team members ask the moderator (often the product owner) questions about themes, user stories, story points, product backlogs, agile retrospectives, or whatever else they need for their agile estimating and planning process. Questions typically surround the product owner's acceptance criteria. Questions can include whether the backlog items are complete and what the next best step is to complete the sprint.
• Once the moderator answers the agile team's questions, each team member selects a card estimate. That represents how long they think the work item will take.
• Team members then place their cards, face down, on the table or use a Jira plugin for distributed teams.
• Playing cards are placed face down to prevent anchoring, or influencing each other's evaluations.
• The moderator reveals the Scrum team's cards to view their estimates.
• If team members have a high or low estimate compared to other team members, they need to explain their reasoning. The agile team can ask more questions for clarification. This questioning period is often limited by using an egg timer.
• The process is repeated until the agile team agrees on the estimate of how long it’ll take to complete each user story.
• Agreement is frequently reached on the second or third draw of the playing cards for each work item.

Agile estimation that involves the whole team

Planning poker is an accurate, collaborative, team-building method of estimating the work for each user story.

While you prepare to use planning poker in your next product roadmap planning meeting, consider Easy Agile TeamRhythm. The app helps you group Jira items into themes so stakeholders can easily keep track.

One of the core functions of an agile software development team is effort estimation. You can't properly prioritize a product backlog without first having an idea of the amount of work it will take to finish each of its user stories. One agile estimation technique is planning poker. Agile development is a collaborative pursuit, and planning poker is a consensus-building exercise that gets your entire team involved in the estimation process.

Software development teams use planning poker to assign effort (for example, story points or ideal days) to items in their product backlog. Sometimes also called Scrum poker, it's a gamified way to build consensus by allowing all of the Scrum team members to participate in the estimation process. Physical or digital poker cards are used to facilitate a collaborative planning session. ♠️

Here, we give you a how-to guide to planning poker. First, we'll show you how to play it in the context of a sprint planning meeting. Second, we'll look at some of its benefits as an estimation technique. Then, we'll see why planning poker can be used in product roadmap planning. It can help get your stakeholders involved in a consensus-building estimation session around your product's customer themes.

Playing planning poker — agile collaboration

One of the critical activities for agile teams during a sprint planning session is estimating the amount of effort it will take to complete each user story in the sprint. A common way to do this is to allow a single person, like the product owner or a software developer, to assign story points to each user story. Alternatively, you can use planning poker as an estimating technique to get the whole team involved.

A planning poker session is a fun and collaborative way to gamify sprint planning. After all, the Agile Manifesto highlights the value of collaboration and interactions in software development. Planning poker is a great way to adhere to those agile principles.

So, it's sprint planning day. When your team members are gathered, do the following:

1. Set the stage. If your team is new to planning poker, explain the process. They'll use playing cards to estimate the size of each user story in the next sprint iteration. The product owner or Scrum master will act as the moderator, all team members will play, and there will be plenty of room for discussion and questions throughout the session.
2. Hand out the poker cards. Give each player an identical set of numbered cards. We recommend using the Fibonacci sequence — 0, 1, 2, 3, 5, 8, 13, 21, etc. (To read why this sequence is so effective for estimating, see Mike Cohn of Mountain Goat Software's explanation.) And by the way, if you can't meet in person and are planning as a distributed team, then you can try planningpoker.com as a way to conduct your session remotely. 😃
3. Read a user story. The moderator reads the team members a story from the sprint. They should provide as much detail and context as possible to help the team estimate the work involved.
4. Discuss the story as a group. First, let the team ask any clarifying questions about the user story that was just read. Then, open the floor for discussion — each team member can describe what it will take to get the story done, any dependencies blocking the work, and who on the team might need to be involved in its effort.
5. Play cards. Now, it's time to play the game. Each team member submits a card (face down!) to the moderator. When all the playing cards are submitted, the moderator reveals what each one estimates. In an ideal world, all of the numbers match! This means there is perfect team consensus about the effort required for that sprint item and you can move on to the next one.
6. Discuss and estimate again. Most likely, there will be some difference in the initial estimates. This gives each team member a great opportunity to provide support for why their estimates were either higher or lower than the others. Then, you can do another round of submitting and revealing cards to see if there is further consensus. Tip: Let the moderator decide when to end the round. Remember, you don’t need a perfect story point consensus for every user story.

You did it! Your sprint is planned, and the entire team gained a shared understanding of how each member perceived the effort and work needed to get each user story done.

The benefits of planning poker agile estimation

As an agile estimating and planning technique, planning poker has its pros:

• It encourages collaboration. As a cross-functional team, it's important that each team member has a voice during the estimation process. As each estimator provides their perspective on a user story, the group better understands how they arrived at their conclusion.
• It drives consensus amongst your entire team. With each round of planning poker, the team’s estimates are more likely to converge.
• It has documented merit as a more accurate way to estimate (versus a single person providing the estimates).

In a study published by ScienceDirect, planning poker was used to estimate half of the work of a software project. There were two discoveries. First, planning poker estimates were statistically higher than individual estimates. Second, the poker estimates turned out to be more accurate than the individual estimates for the same tasks.

Planning poker for roadmap planning

Planning poker is a fun and effective way to gain an accurate estimate for your product backlog items. But, why not also use it for strategic planning sessions like roadmap planning?

In our definitive guide to product roadmaps, we discuss how roadmaps focus on big-picture, customer-centric themes, as opposed to individual features. We also highlight that developing your product roadmap should be a collaborative process (just like sprint planning) and should involve multiple stakeholders.

So, go back to the steps above. Think about how you can use planning poker cards to get your relevant stakeholders to estimate the relative size of each customer theme in your product roadmap. It will be a fun way to get a big-picture consensus of your organization's product vision.

Grouping your themes

Planning poker is a collaborative way to get the whole team to help estimate the work involved in a user story. It drives consensus and tends to be more accurate.

If you use Jira to conduct your sprint planning meetings, you already have a tool that organizes your user stories and product backlog. As you try planning poker in your next product roadmap planning meeting, give Easy Agile User Roadmaps for Jira a look. It provides the ability to group Jira items into themes that your stakeholders can easily see. Happy playing!

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

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

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

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

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

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

1. Don’t panic (about distributed agile)

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

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

2. Lead people on how to work from home

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

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

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

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

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

3. Encourage information sharing

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

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

4. Get the right tools

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

Depending on their role, they may need:

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

5. Look at this as a pilot

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

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

6.Trust your people

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

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

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

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

7. Stay social

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

8. Get better at risk management

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

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

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

9. Look on the bright side

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

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

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

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

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

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

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

The development of lean agile

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

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

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

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

The benefits of lean agile

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

Waste less time

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

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

Reduce costs

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

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

Improve work quality

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

The five principles of lean agile

There are five core principles for implementing lean methodology:

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

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

1. Identify value

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

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

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

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

2. Map the value stream

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

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

3. Create flow

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

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

4. Establish a pull system

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

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

5. Seek perfection

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

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

Lean agile made easy

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

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

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

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

The lean methodology is all about eliminating waste and improving efficiency to maximize and deliver consistent customer value. Under lean, if a process doesn’t bring value to the customer, it’s considered wasteful and is eliminated or reduced as much as possible. It’s a development method and guiding mindset that helps teams refine their processes in the name of efficiency, effectiveness, and continuous improvement.

Here, you’ll learn about the origins of lean as well as 7 key benefits of adopting the lean methodology.

An intro to lean methodology

The lean methodology grew out of lean manufacturing. The concept was introduced in manufacturing to improve profits by reducing costs as opposed to relying solely on increased sales. If a company can eliminate waste and become more efficient, it can save money, which increases overall profits.

While the roots of lean manufacturing can be traced back to the 1400s, Henry Ford first fully integrated the entire production process, creating something called flow production in the form of an assembly line.

This was a revolutionary change in car manufacturing, but while Ford certainly enhanced flow, he didn’t leave much room for variety. In the 1930s and ‘40s, Japanese manufacturers Kiichiro Toyoda, Taiichi Ohno, and others at Toyota made a series of simple innovations that allowed them to provide both continuity in process flow and a wide variety of vehicles, creating the Toyota Production System.

This form of lean production enabled the elimination of waste, reduced costs, increased efficiency, and made information management simpler and more accurate. Lean methodology was further distilled and explored in the books The Machine That Changed the World by James P. Womack, Daniel Roos, and Daniel T. Jones, and Lean Thinking by James P. Womack and Daniel T. Jones.

The latter book also introduced the five key principles of lean:

1. Identify Value
2. Map the Value Stream
3. Create Flow
4. Establish a Pull System
5. Seek Perfection

Learn more in our article, Understanding Lean Agile and the 5 Lean Principles.

Of course, lean thinking has evolved beyond manufacturing and has been adapted and applied to everything from healthcare to construction to logistics and distribution to government to software development.

1. Increased efficiency ⏳

The application of lean to business processes is all about reducing waste to increase efficiency. But how do you figure out which processes provide value?

Once customer value is identified, teams can create a value stream map. Value stream mapping tracks each of the steps and processes to bring a product from inception to delivery. Organizing your processes visually where everyone can see them allows teams to clearly see what does and doesn’t provide value. If any steps or processes don’t bring value to the customer or are found to be otherwise wasteful, they are eliminated or reduced as much as possible.

A team can’t be efficient if they’re wasting time on tired processes that don’t provide customer value. Adopting lean methods helps to get rid of those processes, so you can dedicate your team’s energy exclusively to the processes that do, thereby increasing your team’s value flow, efficiency, and productivity.

2. Reduced bottlenecks 🛑

A bottleneck or broken process, no matter how small, can totally derail a workflow or make it impossible to meet a deadline.

With lean, tasks aren’t blindly or randomly assigned. Teams work together to ensure work is evenly distributed and deadlines are met. They discuss any potential bottlenecks in advance so they can be solved before they become a financial burden or delay work. Since capacity and WIP (work in progress) items are continually forecasted, monitored, and adjusted with lean, bottlenecks are anticipated in advance, every team member participates, and no one’s time is wasted.

3. Fewer costs (and fewer surprises!) 💸

Eliminating waste means saving money—no matter the industry. Overproduction, having too many materials to store, overhiring, and production bottlenecks are expensive and wasteful. These wastes can be eliminated with better management of processes and systems, enabling companies to always have the right number of employees, amount of materials, and working hours at any given time.

Adopting the lean methodology means increasing efficiency, which benefits any company’s bottom line. Make sure every cost is accounted for and necessary to the production process by consistently reviewing your company’s work processes and eliminating any costs that don’t add value.

4. Systems can adapt better and faster 🌎

Businesses today must adapt faster than ever due to increasing customer demand, rapidly evolving technological advancements, and the COVID-19 pandemic.

The larger the size of the organization, the harder it is to adapt. Long-running business systems were not designed to be flexible, so when adjustments need to be made, it may take months or years before the entire organization is on the same page.

With lean, teams can better adapt. Lean systems aren’t as rigid, so it’s easier to make adjustments along the way, meaning teams will better adjust for unexpected circumstances. The lean methodology can help any business, no matter its size, adapt to changing times gracefully, as lean is the exact opposite of a set it and forget it process.

5. Stakeholder visibility and strong customer relationships 💞

The lean methodology leans into both stakeholder and customer needs, which results in a better end product. Progress in lean is measured based on the value delivered to the customer instead of the completion of tasks.

With lean, customer value is paramount. Every project and task begins with considering the point of view of customers and putting yourself in their shoes. Feedback is gathered alongside product development instead of at the end to ensure new information is considered and that the final product will be exactly what the customer needs or wants.

6. Continuous improvement mindset 🧠

Lean is the enemy of the status quo. Lean demands the constant fine-tuning and refinement of processes and enables a continuous improvement mindset. It’s not a “set it and forget it” process, as lean is all about consistent process improvement. No matter how successful or efficient the company is, there is always room for improvement and new, innovative ways to bring value to the customer.

This attitude instills a continuous improvement mindset in everyone involved on the team, whether it’s a small development team or an entire lean enterprise (SAFe). Teams can anticipate and expect regular feedback from leaders, managers, and stakeholders. With lean, innovations and iterations are less precious and more plentiful. The team continues to improve and fine-tune their skills and processes with each passing product.

7. Increased team engagement 🤝

Employee disengagement is expensive. Disengaged employees have higher absenteeism, lower productivity, and lower profitability — all of which can majorly drain a company’s resources. If a company’s culture doesn’t inspire employees to show up and do their best, that company is going to hemorrhage money every year until its bottom line bottoms out.

A lean organization, on the other hand, puts teams on the frontline of product development. Under lean management, employees have direct and regular contact with managers about how their work is going and how the process could be improved. Since teams are more involved in the process, they are more engaged and more likely to actively participate, provide feedback, and buy into their work.

Engaged employees are a company’s greatest asset. Bringing everyone into the process gives teams ownership over the outcomes, boosting their creativity as well as their accountability. Increased team engagement means enhanced efficiency, effectiveness, and team morale.

You can apply the lean methodology anywhere to reduce waste and improve efficiency. Let’s recap. The top benefits of adopting lean include:

1. Increased efficiency

2. Reduced bottlenecks

3. Fewer costs (and fewer surprises!)

4. Better and faster systemic adaptation

5. Stakeholder visibility and strong customer relationships

6. Continuous improvement mindset

7. Increased team engagement

Agile made easy

Easy Agile can help your agile team work better together to deliver for your customers. We have a suite of agile apps for Jira designed to put the customer first through every step of the product development process. From team agility with Easy Agile TeamRhythm, to scaled agility with Easy Agile Programs, our plugins work with multiple agile frameworks, including Kanban and Scrum.

If you work with Jira, you’ll find our lean tools especially helpful for improving the functionality of your workflows and enhancing team collaboration.

Lean principles focus on delivering greater customer value by using minimal resources. Enterprises use these lean principles to practice continuous improvement based. They base their improvements partly on the practice of zero waste.

Here, you can improve your knowledge about lean principles to increase productivity. You can also use software tools to support positive change in your work environment.  A lean-agile team is more productive and team members get to share their new knowledge.

The history of lean principles

Inspired by Ford’s mass manufacturing system, Eiji Toyoda created the "Toyota Production System.” This served their customers and introduced "Just-in-Time" (JIT) manufacturing.

JIT means only stocking enough vehicles to streamline rapid production. By only keeping an inventory of required parts on hand, a company saves money and time.

Starting here, the lean methodology has evolved over time. Now, lean consists of three main concepts of purpose, people, and processes.

The purpose of lean concepts is to give the customer what they want, reduce waste, and focus on employee morale. It also encourages accountability. Lean promotes ownership of work, problems, and successes.

Overview of lean principles

Organizations use lean principles to enhance overall performance. They do this by being careful how they use their scarce resources to meet customer demand.

The concept and practice of lean principles include:

1. Elimination of waste
2. Incorporating quality via end customer value
3. Generating knowledge among team members
4. Postponing workflow commitments
5. Produce rapid delivery
6. Respecting people
7. Encouraging holistic process improvements

Practicing the lean principles

The lean principles require lean processes and lean tools. Therefore, if you want a lean organization, the leadership must support lean thinking and provide employees (people) with the tools to achieve this aim.

Here’s how to enact the lean principles:

Focus on value

This means producing products that customers want by encouraging them to provide details and feedback about products and services.

Kaizen is a part of Japanese philosophy that highlights the elimination of waste in a quest to change for the better, thus producing greater customer value.

Use value stream mapping

This process involves mapping out all the people and the actions needed to deliver a desirable end product. You get to see which processes work and which do not add value. You also have a better chance of identifying bottlenecks before they become a problem.

Once you do a bottleneck analysis, you can eliminate obstacles and improve processes. A bottleneck analysis involves getting to the root cause of what is holding up completion of the work and finding better processes to align all work batches that are dependent on each other.

Develop a logical workflow

To do this, you’ll focus on implementing the correct steps to create value in a logical sequence.

You can help streamline workflows by using Scrum sprint principles and break the work into smaller parts. You can also use tools like strategic roadmaps to visualize and improve Scrum or Kanban workflows.

Develop a pull system

A pull system ensures that teams know what to do and when, so they use less effort in creating outputs.

A pull system responds to demand. If there is a demand for a product, you respond by doing whatever is necessary to meet that demand. Knowing there is demand helps reduce non-value processes and optimize resources by using JIT or Kanban.

Encourage continuous improvement

You can use the Kaizen approach and other elements of the lean philosophy to enhance continuous improvement by constantly finding ways to do things better.

One way to do things better is to continue checking your value stream mapping to ensure that everyone stays on board. You must also ensure that all employees participate in lean processes and actively look for ways to improve the supply chain.

The benefits of implementing lean processes

Any organization that wants to take the lean principles route can anticipate some excellent benefits.

Several of these benefits include:

• Improving team member and team communications
• Empowering people to make decisions and engage in ongoing positive change
• Developing integrated cross-functional teams who share knowledge and skills
• Enhancing end goal delivery to augment end customer value
• Reducing the overall time to deliver that value to customers

Besides using Scrum stand-up meetings and software development tools and processes, you can use more lean tools to create a team or organization that embraces lean thinking.

Lean principles tools

Organizations can use metrics such as sales data and customer feedback as tools to assess customer demand. But, only after identifying the value can organizations use the lean tool of value stream mapping to further their end goal.

You can also browse through the information resources at the Lean Enterprise Institute to learn more about lean principles. You can also explore other lean thinking such as Six Sigma, Error Proofing, Plan-Do-Check-Act (PDCA), and other tools to support a lean organization.

Jira software tools from Easy Agile

Easy Agile provides organizations and teams with multiple tools to help streamline their workflows. For instance, you can use Jira to help develop logical workflows and get your teams up to speed on lean thinking.

Tools like Easy Agile Scrum Workflow for Jira are available at no cost to ease this positive change. Another tool that complements value stream mapping is Easy Agile Programs for Jira.

Adopting lean principles is much easier with the support of Easy Agile resources, so get your lean team going today.

Kanban vs. Scrum — are they different, and can software and product development use them together? The answer to both questions is YES!

Both Kanban and Scrum are popular agile methodologies. They are different, but they can be used together. They are each part of agile, a better way of working that focuses on iteration and collaboration to reduce waste and maximize efficiency.

Agile is the antithesis of classical project management. Think of it like jazz vs classical music. Rather than one composer bringing an already composed and organized piece of music to an orchestra and dictating what happens where, jazz is collaborative, each band member feeds off of each other, creating music in an agile, iterative process.

This post will take a deep dive into both Kanban and Scrum methodologies. Continue reading to discover the differences and similarities between Kanban vs. Scrum, and learn how they can be effectively used together.

How is the agile methodology different from project management?

The traditional project management methodology is linear, meaning each project element is completed in sequential order. Only when each element is completed can you move onto the next one. Think of traditional project management as an assembly line. It has a strict succession of steps that are planned out by the project manager before any new work or iterations can begin.

The project manager is the person the entire team depends on for leadership. The flow of work remains the same from project to project, and the steps rarely evolve.

By contrast, agile is a non-linear way of working that focuses on flexibility and collaboration between team members. Agile project management focuses on getting something completed that stakeholders can see and evaluate on a regular basis, so value is continuously provided.

Each iteration yields new, actionable insights from both the team and the customer about what’s working, what isn’t, and what needs to change. It’s a multifaceted approach that eliminates the bottlenecks that can arise in the traditional method.

Kanban vs. Scrum

Kanban vs. Scrum is not a dichotomy. They are both agile methodologies designed to help teams work in an iterative process. They are both systems that are regularly used in the development process to ensure a value-driven approach. The goals and methodology are the same, but the steps are different.

A Kanban workflow is a way to visually organize tasks that ensures work items move forward while allowing changes and adjustments to be made along the way. A scrum works in 2-4 week sprints designed to complete a set amount of work or solve a specific problem. Throughout each sprint, teams check in daily to ensure progress and to identify any possible roadblocks.

Kanban vs. Scrum isn’t a one or the other choice. Both might be used at the same time, depending on what’s required of projects or user stories. Learn more about the differences and similarities of these two methods below.

Kanban vs. Scrum: Kanban methodology

Kanban was originally utilized by Taiichi Ohno, an engineer at Toyota, as a lean manufacturing system that decreased waste and increased efficiency. The Kanban method is a task management tool designed to maximize efficiency by visualizing all of the required work and limiting works in progress.

Work items are represented visually on Kanban boards so that every team member can see the state of each piece of work at any given time. It enables real-time communication and full transparency between team members since each work item is intentionally assigned. A Trello board is a simple example of a Kanban.

How to use Kanban

With a Kanban, work flows visually through various stages of completion to promote cohesive collaboration and real-time communication across teams. In its simplest form, a Kanban is a To-Do, Doing, and Done board. Work moves from one section to the next on a physical or digital Kanban board, depending on how far along the specific task is.

To solve more complex problems, which is usually the case in software development, a Kanban can become more advanced with added layers for specific clients, products, or deliverables.

A key aspect of the Kanban methodology is that each person is only allowed to work on one task at a time. This ensures no aspect ever moves too far forward without working in unison with the rest of the tasks on deck. The one-at-a-time system identifies critical connections between tasks as well as potential roadblocks that could cause delays.

Encouraging cross-functional teams to intentionally identify work items ensures tasks are appropriately prioritized. It also combats the negative effects of multitasking, allowing developers to zero in on one task at a time.

Kanban vs. Scrum: Scrum methodology

Scrum, sometimes called a “scrumban,” is based on empiricism and lean thinking. Empiricism is the belief that knowledge comes from hands-on experience and objective, observable facts. Lean thinking focuses on the essentials, bringing value to individuals while eliminating waste. A scrum uses real-time collaboration over theorization to provide a lightweight framework for solving complex problems.

The Scrum process uses an interactive and incremental approach that manages risk and enhances predictability through set intervals of iteration called sprints. The sprints yield an imperfect but valuable version of a product the team can quickly bring to stakeholders, whose feedback is then integrated into the next sprint. The sprints continue until the desired outcome or product is achieved.

How to use Scrum

A Scrum takes place over a set amount of time called a sprint. Each sprint generally takes two weeks to a maximum of four weeks to complete. The important part is that the time frame is set before the Scrum begins.

There are three main components of a Scrum:

1. Roles: The people

• Product owner
• Scrum master
• Development team

2. Artifacts: What gets done

• Product backlog
• Sprint backlog
• Increments

3. Ceremonies: Recurring events

• Sprint planning
• Daily Scrum
• Sprint review
• Sprint retrospective

The product owner orders and prioritizes backlog items, which are the aspects of a product that need completion. At the beginning of a Scrum, the product owner designates which artifacts from the product backlog move to the sprint backlog. The sprint backlog represents the goals and the desired outcomes of the upcoming sprint.

💡 Use Easy Agile TeamRhythm to transform flat product backlogs into impactful, visual representations.

The Scrum master helps everyone understand Scrum theory and practice. They are responsible for the effectiveness of the Scrum team. Throughout the 2-4 week sprint, the team focuses on the backlog, checking in for daily scrums or daily stand-ups. During these Scrum meetings, team members share what story points they completed, what story points they will complete next, as well as any roadblocks that stand in the way.

Deliverables are produced on a regular basis, and adjustments are made along the way as needed. A Scrum board or Kanban board might be used to help teams visualize their progress throughout the sprint.

Ceremonies are the recurring events held by Scrum teams cycling through on a 2-4 week basis. A Scrum begins with a short planning phase, then the work begins. The Scrum team meets daily to review progress and make changes as needed.

At the end of each sprint, a sprint review is held with stakeholders or clients to ensure value is being met, and continuous improvements are pushed forward. Lastly, a retrospective meeting takes place with the project owner, scrum master, and development team to review the past two weeks, including successes, key metrics, and challenges to be addressed before the next sprint begins.

Using Kanban and Scrum together

It doesn't need to be Kanban vs. Scrum — they can work together. A development team might choose to use the Kanban system within a Scrum to provide a visual representation of work moving forward throughout each sprint.

They are both valuable systems in your agile toolkit that work together to provide prioritization, collaboration, and constant value delivery. So, you don’t ever have to choose between Kanban vs. Scrum. Save the decision-making for the real problems, like what to put on the pizzas you order for your team. 🍕

A Scrum framework provides designated blocks of time for teams to complete a specific deliverable or set of deliverables while providing daily Scrum meetings to ensure cohesion and advancement. The Kanban system will ensure tasks are taken on one at a time in an evolving, visual process.

Learn the ways of the Scrum with Easy Agile

Easy Agile crafts solutions to make every agile team more effective. We help teams build simple and collaborative user story maps in Jira for backlog grooming, version planning, and silky-smooth sprints.

We believe there is a better way to work, and we want to help teams just like yours. Learn more about our suite of agile apps and follow our blog for the latest agile trends, tips, and more.

What is a customer persona?

Customer Personas are fictional generalizations of your most valuable customers.

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

What are user personas?

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

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

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

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

Building customer personas helps teams to address the following questions:

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

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

Firstly, broadly define your personas

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

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

Secondly, look towards insights and analytics

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

So where can we find this information?

Look at sources like:

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

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

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

Customer personas in Jira

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

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

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

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

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

Try it now

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

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

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

Why write user stories?

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

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

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

What is a user story?

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

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

A User Story = the 'what'

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

User stories divide features into business processes.

A task = the 'how'

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

Tasks are individual pieces of work.

How do we write user stories?

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

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

Let’s break this down further;

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

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

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

Let’s look at a few simple examples;

As an internet banking customer

I want to see a rolling balance for my everyday accounts

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

OR

As an administrator

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

So that I can delegate tasks more efficiently

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

To write successful user stories:

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

Acceptance Criteria

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

The link pairing these two things together is acceptance criteria.

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

Acceptance Criteria Goals

Acceptance criteria should:

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

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

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

Acceptance Criteria:

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

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

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

Acceptance criteria should NOT include the following:

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

Why?

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

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

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

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

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

Stay focused on your customers

Easy Agile TeamRhythm

Are you keen to ensure your company is customer-centered? One good way to do that is to build personas.

Whether you’re a product owner, marketer, or salesperson, writing your company’s personas is kind of a big deal. (So, probably don’t delegate this job to the intern...)

That’s because your personas can be used to:

• Brainstorm new ideas
• Decide what products and features you should prioritize
• Better target your advertising and marketing creative
• Connect better with sales prospects and recommend the best solution to match their goals, problems, and pain points

Your personas will impact nearly all parts of your organization, so it’s important that you get them right. We know a thing or two about how to create personas (you might even say we’re experts 😏), so we’ve created this little guide to help you create yours like a pro.

Follow our 9 simple steps and you’ll end up with powerful personas that your whole team can use.

Ensure your team are aligned around customer archetypes with

Easy Agile Personas

Free Trial

1. Do your research

The best place to start is with your existing customers and prospects. You could run interviews and focus groups to find out more about who your customers are and what they want. Or create an online survey - you can set these up for free in Google forms.

Ask your customers about:

• Their age
• Their location
• What they’re qualified in
• Their title or job role
• Where they work
• Their family life
• How they’re currently using your product (or other products)
• What’s bothering them about your product (or other products)
• Relevant tasks they struggle with
• What they’d like to achieve in their work/life right now

Tip: it can sometimes feel a bit awkward if you ask personal demographic questions, so you could instead sum them up with one question: “How would you describe yourself?” This allows each respondent to decide how much detail they give you, and you might get some really valuable insights from an open-ended question.

Other research methods include:

• Analytics- Google analytics and social media analytics will usually display demographic Look at your analytics
• Forums- Join forums and closed groups where your audience likes to hang out, ask questions, and share about problems that are relevant to your product or service (just make sure you set a time limit for yourself so you don’t accidentally fall down a Reddit/Quora rabbit hole)
• Talk to your colleagues- Try to get your whole team involved and talking about your audience, especially the ones who regularly interact with customers

2. Analyze the data and identify your personas

Now that you’ve done the research, it’s time to figure out what it means. Keep an open mind as you look at the data because you want to create real personas, not something that backs your own internal narrative or the path you’ve been on until now.

Look for patterns in the data and see what the similarities and differences are. From here, you should be able to identify 3-5 distinct persona types. At this point, you might be tempted to create eleventy million personas, but don’t. You want to cover all your key user and audience types, and get reasonably specific.

Usually, less is best when it comes to personas because it means you can be more focused. After all, you can’t do everything and you know what they say… if you target everyone, you reach no one. The more your product and marketing is tailored to a specific group of people, the more they’ll be drawn to it. This could mean you’ll need to exclude some audiences from your personas who aren’t as good of a fit for you, and that’s okay.

3. Find a persona tool or template

Ideally, you’ll use an app or system that creates personas (like Easy Agile Personas for Jira). That way, you can integrate your personas into your processes, you won’t have to fiddle around with formatting, and they’ll be easier to update.

Some people have persona templates in google docs or Confluence.

Try Easy Agile Personas

4. Make them human

Before you put pen to paper, it’s a good idea to source a photo that helps define who your user persona is. That’s because the more authentic your persona, the easier it will be to relate to them and have empathy with them. And the easier it will be to write about them and come up with their story. When choosing your photo, try to find something that doesn’t look like a stock photo.

Next, give your personas real names that fit their demographics. Try to avoid boring cliches, but if you need some namning inspiration, you can trawl through the lists here.

In the personas, include information that helps you understand them as a person. You don’t need to share their full life story, but adding little details about their personality and motivations can help bring them to life.

5. Write your personas

When writing your personas, it’s all about telling their story (the TL;DR version). Depending on how you plan to use your personas, you might include details like:

• How their day is structured
• How they got to where they are now (in life/career)
• What they’re currently thinking about
• What keeps them up at night

Key sections could include:

• Name
• Demographics (like gender, age, location, qualifications, occupation, income, marital status, and kids)
• Goals/needs
• Values
• Information sources (like books, podcasts, news sites, blogs, TV, radio, thought leaders, and social media channels)
• Technology (including devices, browsers, and software/apps)
• Pain points, fears, and objections
• Personality traits (you might refer to DISC, Enneagram, and even Love Languages)
• Skills and tools
• Quote (a sentence or two in their own words that captures their thoughts or position, ideally a survey answer or quote from interviewing one of your customers)

You don’t have to use all of the above sections. You’ll need to keep your personas succinct (1-2 pages), which means avoiding fluff and editing out details that aren’t relevant or useful.

6. Refine

Now that your personas are written, it’s time to involve the rest of your team and get feedback on the personas. Many of them will have different perspectives on who your personas are and what your audience’s key problems and pain points are. So, let them poke holes in the stories and add other important details you may have missed.

There’s also a side benefit to refining your profiles with the help of your team members. If they’re involved in creating the personas, they’ll be much more likely to use them at the end.

7. Make them pretty

Scrappy personas can work, but if you create a better user experience, your personas will probably get used more often.

You can jazz up your personas with icons, illustrations, and brand colors. Add graphs and charts to visually represent data (like where your persona sits on a personality trait scale). And use headings to break the persona up into sections and make it easier to scan. Dot points, bolding, italics, and highlights can also help key information to stand out.

8. Incorporate them into your processes

Your marketing, sales, and development teams can all do better work when they use personas. So make sure that your shiny new personas are incorporated into all relevant business processes and made accessible to the whole team. Upload them to the cloud, link them to your project management tool (like Jira), and ideally, your user stories and backlog to add context there.

9. Notice the difference

With personas, your teams are equipped with a much better understanding of your users and audience. The impact of this could be that:

You’ll become more user focused

Personas force your team to think about the user first, empathise with your customers, and see them as real people with real needs. For example, your team might want to work on a new feature that allows users to login using Facebook (everybody else is doing it!), but first they check to see how each persona would use this feature. Turns out, none of your personas are heavy Facebook users so it’s unlikely this feature would get used. Instead, your team decides to prioritize updates to the dashboard that could help two of your personas achieve a specific goal.

Your product will improve

If you’re focused on what your users want and need, your product will get better. Linking new features and work to what your personas need will help shape your product and make it more valuable over time.

You’ll see the value in your work

A task becomes more than just a thing on your to-do list when it’s linked to a persona. Your team aren’t just marketers, salespeople, and developers - they’re problem solvers.

Your marketing is more relatable

Personas help your marketing team know your customers better - their problems, goals, desires, and even how they talk. Your marketing team can use these insights to create marketing collateral that’s more relatable and engaging - that talks directly to your personas.

Your comms become more aligned with your releases

For example, your marketing team could filter all of the issues scheduled in an upcoming release by Persona. They might see that the majority of stories the development team will be working on directly relate to the Busy Mum persona. Having this information allows them to tailor their go-to-market communication to the Busy Mum persona, which can help warm up this audience, ready for the new release.

You’ll have your priorities sorted

You’ll be able to prioritize better and justify your actions by bringing it back to your personas. Instead of following your own agenda, your customers’ priorities become your priorities. You can sort tasks by which persona it will benefit and by how much (in Easy Agile Personas, we have an “Importance to Persona” custom field). For example, you might see that your team hasn’t worked on any of theStay At Home Dad persona’s stories for a while, so you shift gears to work on his top priority feature.

That’s why great personas should be your #1 resource when making key business, product, and marketing decisions so that you always look at things through the lens of your customers. Now you’ve got your personas, go forth and create!

Try Easy Agile Personas

If you’re using Jira, we have a super simple way you can incorporate personas into your workflow 👇

Easy Agile Personas is our latest solution for teams that use Jira. Capture personas alongside your team’s Jira board and make it easier for your team to stay aligned on priorities and focus on the most important thing - your customers!

Try the 30-day free trial and see how easy it is to build personas into your team’s everyday tasks!

Easy Agile Personas